MicrosoftIt may be "easy to implement" something that superficially resembles mDNS, but it's not that easy to implement mDNS correctly. One-shot legacy resolution (multicast queries with src port != 5353, yielding non-cacheable unicast replies) is pretty straightforward, but anyone who binds to port 5353 is claiming to be a full mDNS stack and will get multicast replies to their queries which is very spammy unless RFC6762-compliant caching and associated cache-coherency and traffic reduction mechanisms are implemented (all of which are supposed to be mandatory for implementations that bind to port 5353).
That's why normally you'd want to have a single full mDNS stack provided by the OS with a single cache, ideally sufficiently featureful, reliable, and easy to use that applications feel no need to roll their own mDNS (and perhaps some day the OS mDNS stack can stop enabling SO_REUSEPORT).
Applications binding to port 5353 instead of using the OS mDNS stack is generally the result of one of more of:
1. Lack of consistent API across different operating systems.
2. Windows formerly lacking a native mDNS stack, and information about its stack is still kind of lacking. It would be nice if searching for "Windows mDNS" would yield proper documentation on its mDNS stack and available APIs near the top search results, instead of having to fish info out of blogs and stackoverflow posts.
3. Deficiencies in the host mDNS stack. A particularly painful issue in Windows is that it apparently classifies a zeroconf network (i.e. if you just connect another computer or IoT device via Ethernet, no router, no DHCP server) as being a "Public Network" causing it to disable mDNS in the exact situation where it's needed the absolute most.
