mdns failng with current versions of libnss-mdns and avahi-daemon

Also:

[659] /etc/avahi/services $ avahi-browse -a
+ lo IPv4 cid SSH Remote Terminal local
+ lo IPv4 cid SFTP File Transfer local

It's as if something is causing the network interface to not support mdns, but everyhing looks configured to me... what am I missing? It should really not be this difficult...

If the primary issue is that other devices can only resolve your hostname after restarting avahi-daemon for a short time, plus, this machine doesn't see anything else on the network, it means that for one reason or another mDNS packets on port 5353 are not making it back to this host.

The overwhelming majority of such cases are due to a bug in the driver for that network interface, almost always its a wireless interface or some kind - it's rare in wired ethernet drivers but not impossible.

Very often setting the interface to promiscuous mode will fix this, because it tells the NIC to receive all packets (by default NICs filter out packets not intended for the host). You can try this command to set it:
ip link set ens160 promisc on

If this solves the issue, then it's 100% a buggy driver and I cannot do anything about that at the avahi level. You'll need to look at getting the driver fixed. This is common with bad wifi drivers, very rare with ethernet.

If that doesn't help, it could be the driver also doesn't support promiscuous but I've not really seen that before. I would then check
- Firewall on this machine,
- Any features of your wireless network such as "multicast dns optimisation", etc

If you run tcpdump for port 5353 you'll see packets coming and going. I suspect most likely your machine never receives any query packets from another host. So you can try run this command and then running a query from another host:
sudo tcpdump -ni ens160 --no-promiscuous-mode port 5353

You can also try this without "--no-promiscuous-mode" (by default tcpdump puts the interface in promiscious mode, same as the above command).

As a final note the resolvectl/resolved mdns support is totally independent of avahi, having it enabled could cause mDNS to fail in some cases - particularly with a network that performs 'multicast dns optimisation' where the packets are converted from multicast to unicast. Only a single process can bind to port 5353 for unicast packets and the packets will randomly get sent to resolved, avahi, chrome.. or any other process listening on port 5353. So disabling it (and anything else listening on 5353) could help in some specific circumstances though usually not necessary in most cases.

There's a detail in the github issue that wasn't noted here:
I have Ubuntu Server 22.04.2 running in a VM (VMWare 13.0.2) on an Apple Silicon Mac running macOS 13.4.

That makes the network driver situation less likely but the firewall situation still possible.

A few extra questions:
What kind of network is fusion set to - bridged, nat, host-only, etc
+ If you are using bridged, but to your macs wireless adapter, I have also experienced this not working as expected. Try use ethernet via a USB-Ethernet or native ethernet if your machine has it - and see if it works then. That was the case for me. If you google "vmware fusion bridge wifi" there are lots of posts with slightly different setups and symptoms.
+ If you are using nat/host-only I would expect only to be able to resolve hostnames with the host Mac and not the rest of the network

Run tcpdump as directed, I am curious if you see any packets sent from any other node on your network. I am guessing not. If you are, it would be ideal to capture a pcap file (a copy of all the network packets on 5353) from both this linux VM, as well as another linux machine on the network that is not the host mac:L

tcpdump -i <interface> -s 65535 -w lp2021409-$(hostname).pcap port 5353

Then run a query from both the VM and external host, for the other machine. While the pcap is running. Then stop it. Upload both files and note the IP addresses and hostnames of both machines.

It's highly likely this is not a bug in avahi or nss-mdns but a network issue of some kind. Hopefully this will get you going in the right direction.

Note that this system doesn't resolve itself either (unless I configure avahi to use lo as well)

The network is bridged to the Mac's wireless interface.

I'll give bridging to a wired interface a try.