Used multiconnect version: 1.3.34 for 1.16.4
Servers native version is 1.11.1

If the player tries to shift click smeltable items into a furnace the client will think they are not smeltable causing it to put it clientside in the wrong spot. Cause propbably are furnace recipes which aren't added by multiconnect (Recipes_1_12_2 class).
The if check that checks the items is in AbstractFurnaceScreenHandler#transferSlot -> Always false if there are no furnace recipes.
This error causes client/server inventory desyncs.

This video showcases the issue (Left = Multiconnect | Right = 1.11.1 Client): https://streamable.com/ac392u

That's weird, iron ore should be smeltable in 1.11 too, I'll look into it

It is but its not added in the Recipes_1_12_2 class of multiconnect (The client doesn't know its smeltable because the recipe isn't registered)

Right, I forgot SynchronizeRecipesS2CPacket includes furnace recipes now. That means this probably affects 1.12.2 and below.

I checked, affects 1.12 as well

Out of interest, because I'm not sure they added furnace recipes to the new recipes system right away, does this maybe affect 1.13 too? What's the latest version it affects?

Although 1.12 servers send the recipe packet already, so multiconnect override it for no reason

It does not affect 1.13 as it doesn't even affect 1.12 if you don't override the recipe packet from the server. In multiconnect it affects <= 1.12.2

No it doesn't. 1.12 doesn't send any recipe synchronization, although it uses recipe jsons. I distinctly remember having recipe ID desyncs in 1.12 carpetmod.

I just looked in MCP for 1.12 theres a SPacketRecipeBook which contains recipe ids which should be added to the recipe book. VV creates a DeclareRecipes packet if the SPacketRecipeBook action is INIT, thats why I thought 1.12 servers send a DeclareRecipes packet

Yes those recipe IDs are calculated independently on the client and the server