Has altering the wire format to contain all the info needed for unambiguous decoding of each message entirely within libwayland without needing to know the object ID -> type mapping been considered?
It would make the messages longer, but this seems like it wouldn't be very bad for performance because wire message transfer is roughly aligned with user interaction speeds. Also, for any compositor/client pair, as long as they both use the same version of libwayland, the necessary wire format change would not result in compatibility issues. It would for static linked cases, or similar mismatching cases (flatpak, appimage, snap, etc. unless the host version is mapped in instead of the packaged one somehow). There also seem to be unused bits in the existing wire format so that one could detect an a compositor/client incompatibility at least on one end. I'm not suggesting that unambiguous decoding of all messages is a sufficient fix, but it is a necessary one. There are still speculative computation issues that it wouldn't resolve alone.
