(former title: Additional fixes seems required for block limit (ClientboundBlockChangedAckPacket))

This fix worked great in large modpacks for certain cases (Diagonal feces and Diagonal windows mods adding to modpack start to corrupt blocks when placed or change state).
However, there are certain mods that use other network packets that seem to depend on states too. For example, if using the Create mod contraption, some blocks also start to vanish (see Creators-of-Create/Create#5419). I have added the Block Limit Fix mod, and now exceptions in the log have changed. Instead of exceptions for "ClientboundSectionBlocksUpdatePacket", I started to receive them for certain other packet - ClientboundBlockChangedAckPacket. Here is an example:

[02Sep2023 00:55:56.464] [Render thread/ERROR] [net.minecraft.util.thread.BlockableEventLoop/FATAL]: Error executing task on Client
java.lang.NullPointerException: Cannot invoke "net.minecraft.world.level.block.state.BlockState.m_60734_()" because "p_46606_" is null
	at net.minecraft.world.level.Level.m_6933_(Level.java:198) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.client.multiplayer.ClientLevel.m_6933_(ClientLevel.java:165) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.world.level.Level.m_7731_(Level.java:188) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.client.multiplayer.ClientLevel.m_233647_(ClientLevel.java:142) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.client.multiplayer.prediction.BlockStatePredictionHandler.m_233856_(BlockStatePredictionHandler.java:44) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.client.multiplayer.ClientLevel.m_233651_(ClientLevel.java:129) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.client.multiplayer.ClientPacketListener.m_214108_(ClientPacketListener.java:2109) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.network.protocol.game.ClientboundBlockChangedAckPacket.m_5797_(ClientboundBlockChangedAckPacket.java:19) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.network.protocol.game.ClientboundBlockChangedAckPacket.m_5797_(ClientboundBlockChangedAckPacket.java:6) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.network.protocol.PacketUtils.m_131356_(PacketUtils.java:22) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.util.thread.BlockableEventLoop.m_6367_(BlockableEventLoop.java:157) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.util.thread.ReentrantBlockableEventLoop.m_6367_(ReentrantBlockableEventLoop.java:23) ~[client-1.19.2-20220805.130853-srg.jar%23723!/:?]
	at net.minecraft.util.thread.BlockableEventLoop.m_7245_(BlockableEventLoop.java:131) ~[client-1.19.2-20220805.130853-srg.jar%

Did you install the mod on the server or client? It's needed on the server.
This is a new error, but the same root issue. The server is sending the client invalid block data. This mod patches the only time this happens in vanilla, so I think some other mod has to be interfering. I do not think it's Create, it does not touch this area of code.
Also make sure you have the exact same mods and mod versions as the server.

Yes, I installed both client and server.
Yes, all versions match. Also, I have checked that all block and item ID tables match between the client and server (means, no content mismatching between mods).

As I described in the Creators-of-Create/Create#5419, I have tried to remove groups of mods and see if this stops happening. It did not work, but it was before I applied Block Limit Fix. I will try it again and let you know if there is any relation to some other mod. However, I doubt it, because the problem goes away as soon as I remove a number of mods, especially ones that add a lot of block states.

Removing sets of ~20-30 mods one by one did not help - the problem persist, so it is not some mod that is involved. (Or if there is such a mod, I have a few of them, that probably means some generic issue anyway.)

Today, after adding some more mods for heavy load/testing of the issue, I discovered that Diagonal fences and Diagonal Windows mods started to spoil blocks again (removing them stops blocks corruption.) More, there are no exceptions in the logs for this case. Block state change in the world (simply pressed that copper button from one of the mods!) turns that block into something else.

It means "Block limit fix" did not actually help here. It appears that the "too many states" issue is buried deeply in many places of the Minecraft code and packets.

If you want, I can network-debug the moment of the button pressing when it turns into something else. Can do the same for the contraption I described for Create mod (when exceptions appear). Unfortunately, I do not have a way to see/log packets content.

It looks like, for the time being, the only option for me right now is simply to reduce the number of mods, especially mods that add a lot of content. (Furniture mods will be my first target...) I will keep the "Block limit fix" mod for a while, just for a case :)

@TropheusJ, it appears this mod is not working under the 1.19.2 at all. Whatever I did, I'm getting the same result: blocks with high ID values are not correctly refreshed by Create mod. Digging a little bit more into the logs, I found the following messages related to the block_limit_fix loading:

[23Sep2023 13:53:01.583] [main/WARN] [mixin/]: Error loading class: net/minecraft/network/play/server/SMultiBlockChangePacket (java.lang.ClassNotFoundException: net.minecraft.network.play.server.SMultiBlockChangePacket)
[23Sep2023 13:53:01.583] [main/WARN] [mixin/]: @mixin target net.minecraft.network.play.server.SMultiBlockChangePacket was not found block_limit_fix.mixins.json:ClientboundSectionBlocksUpdatePacketMixin

Indeed, when taking a look inside of the ClientboundSectionBlocksUpdatePacketMixin.class, it contains a reference to SMultiBlockChangePacket.

What I suspect:
From what I saw, SMultiBlockChangePacket is a deprecated class that is no longer used in Forge 1.19*, at least I could not find it in the docs. It looks like this mod, while trying to support multiple MC versions, cannot load on 1.19.2 because of the above issue.

Please, can you create a separate dedicated 1.19.2+ version of this mod that will run correctly?

Made my own 1.19.2 build separately. It worked! Please, make an update.

new versions have been published. thanks for investigating.
This was caused by the class being renamed with the mappings change on forge 1.17.