This would be a simple addition where the objects to write to a packet's byte buf are first passed wholesale to a lambda expression, which is then called on the netty's event loop to actually write into the buf and to be sent.

The writing of packets on the engine thread would not be too much of an issue, but it may become overwhelming if massive amounts of data are sent, such as tag synchronization, in which vanilla already does write to the buf on the netty event loop instead.

The addition of the API would be simple: a few new methods in https://github.com/FabricMC/fabric/blob/1.17/fabric-networking-api-v1/src/main/java/net/fabricmc/fabric/api/networking/v1/PacketSender.java would suffice. This would not touch how packets are received or add new methods to create packets.

Asking @Technici4n, @modmuss50, and @sfPlayer1 for feasibility evaluations.

So this would be to move serialization of a massive amount of read-only (otherwise this leads to a race condition) data from the main thread to the network thread?

yes. in the javadoc, i will document that the data to write should not be modified, so for example, the item stacks should be clean copies and the list containing data be untouched/unmodifiable.

This has a smell of optimstic optimising, has it ever been an issue when building the packet buffer has been slow? I think it would be a good idea to have a few numbers to prove that this is worth it.

@Technici4n I think this can be simple as calling a supplier on the netty event loop for the buf, and changing the buf parameter to a supplier. This still may be beneficial when making massive packets.

I would recommend finding a case where it is an actual issue first, otherwise this will just clutter the issue tracker forever. At least that's why I closed it in the first place.