I've seen the other conversations on this forum about unicast sACN not being implemented for whatever reasons, and I would just like to point out that almost every other major console in the industry (including your own Hog4 line!) can unicast sACN data - except the Eos.
I have seen unicasting fix many many more problems than it would've caused, especially since without an expensive / fancy / managed switch and the pre-requisite knowledge on how to use it, there is no good way to see the switch's ARP table and tell if multicast is properly working without opening WireShark on a computer and then stopping and starting a multicast stream to watch for the group join / leave messages - assuming the switch picked up on it.
I have run into serious enough issues (AKA was not able to deliver a feature to a client because of lack of EOS unicast sACN) on two recent high profile gigs and had to point to those forum posts and lay the blame at ETC's feet because in every other situation with other consoles, we can unicast to simplify the networking setup and get around numerous very edge-case and unforeseeable limitations usually induced by complex networking setups with highly mixed vendor environments. Some examples I have experienced that don't SEEM like they should be a problem, but still have been are: VLANing and switch bridging / routing configurations on other departments' networks (that I have no control of or insight into) have regularly blocked multicast but allowed unicast through (sometimes vice-versa) or in some situations where multicast is not supported (or a switch thinks it isn't) said switch "falls back" to broadcast, potentially flooding the network with redundant data that would otherwise be contained if we were using unicast.
In addition, there are some more esoteric or custom / bespoke pieces of software and hardware that either implemented multicast poorly, or just don't support it at all. With the advent of more LED PixelMapping setups and custom show control / data integration / experiential / interactive stuff, the possible range of equipment we may be interacting with is expanding greatly. Flexibility is much more desirable than "rigid adherence to best practices", especially on large scale live corporate temporary events. I can understand how doing things the "right" way are maybe more sustainable in longer-term / permanent installation situations, but when time is of the essence and it has to "just work" for a short period while we are there directly supervising it anyways, unicast is a valuable tool in the tool-belt IN ADDITION to multicast.
In relation to my specific recent circumstances, I am also pursuing the manufacturers / developers of the improperly implemented multicast, but at least their response is actively trying to fix it instead of brushing it off as "unnecessary". And in fact, based on how convoluted and clunky dealing with networking on an EOS still is (you have to DROP into the SHELL??) I almost would assume it's more of a CAN'T be implemented because of "poor network stack design" than a WON'T be implemented because multicast is the "superior" solution...
