I slept, calmed down, and now let me respond: In practice we would like a client of mod loader X and server mod loader Y to be able to connect. This requires at least some cooperation between each other, because the sending party will need to know if it can expect a response, or if the payload that it wants to send runs into nothingness, and it should rather do something else. This can trivially be achieved by telling the other party what channels currently are available, and this is what minecraft:register and minecraft:unregister achieve. If this is all that is needed, then we all go home. Dinnerbone did this work already, it is an established standard and there is nothing we can and need to do. This has worked for nearly 15 years, is simple, easy to implement and stable. Unsuiteability However, several parties involved have indicated that this, limited exchange of information, is not sufficient to provide a proper mechanic that ensures the different loaders can work together. Minecraft has changed. Its network protocol has gotten more advanced with new phases, the ability to configure the client from the server, and now coming down the line custom codecs, as well the ability to change the server using a simple packet. Additionally mojang, in its infinite wisdom, requires that the client and server have the same information. Mods make this assumption as well. Great examples of this are registry ids being used to compress packets instead of using the relatively large names. So the parties which previously indicated that the old protocol was not sufficient came together and discussed what they needed. Fabrics proposal