isokissa3

Going to add that this will also poison all other item components that hold said items. You can also reproduce this with shulker boxes too.

Give yourself two identical shulker boxes that only differ in the tool_display component:
/give @p minecraft:shulker_box[container=[{slot:0,item:{id:"minecraft:diamond_axe",components:{"minecraft:tooltip_display":{"hidden_components":[unbreakable,lore]}}}}]]

/give @p minecraft:shulker_box[container=[{slot:0,item:{id:"minecraft:diamond_axe",components:{"minecraft:tooltip_display":{"hidden_components":[lore,unbreakable]}}}}]]

Now perform the same steps mentioned in OP.
You will notice that the first shulker box's hash is -1241602278 and the second one is 989085267.

Looks like this is indeed fixed. The fix was implemented inside BlockableEventLoop#execute to prevent recursion from occurring in any scheduled task. Previously it would always execute the task inline when called from main thread but now it schedules it for the next tick if the task would result in recursion.

Default thread stack size can differ across multiple platforms and JVM implementations, so not entirely unsurprising, but a bit unexpected given the very deep stack in the repro.

I personally tested this on Windows 24H2 coupled with the JVM that's shipped together with the Minecraft’s launcher.

You also have to replace the files if you somehow loaded in and want to try again, as that calculation is done only before the player has spawned in the world for the first time.

Regardless, the code here is flawed as it permits deep recursion (generally a bad thing and should be avoided, as the stack size is limited) and can be easily eliminated by changing the approach to be iterative.

You can reproduce this by sitting in lava and then flying in to a water.