Pehkui made a breaking change in 3.0.0 . Although @Virtuoel PRed Immersive Portals to update the API usage for 1.18, @Virtuoel did not PR IP for 1.16 and 1.17, so that IP in 1.16 and 1.17 is incompatible with the latest Pehkui.
Pehkui has made breaking changes twice. Incompatible changes break EVERY mod's EVERY version that use the API. If MC 1.19 releases, and then Pehkui makes an incompatible change again, then IP 1.16, 1.17, 1.18, 1.19 must all update to adjust to Pehkui API changes. This is unacceptable.
To avoid that, Pehkui should guarantee that either

• Pehkui never remove any of its API from now on
  or
• Incompatible API changes only occur in the latest MC version (then Pehkui should provide different jars for different MC versions)

The old API is still around in Pehkui 2.6.0, which was released at the same time as 3.0.0.
It was removed so hastily due to crashes related to it reported shortly after release by some mods that used Pehkui's API.

Ideally there should not be a need for me to do hard removals. While I can do further testing to ensure added APIs are stable and removals don't happen again, I can't predict the future.

However, your second point reminds me of something I do with the internal API of one of my other cross-version mods. I shall look into using a similar technique so that old APIs when using past versions can hopefully remain stable.

I still don't understand why removing the old API can fix the crash. Can you explain it in detail?

Around v2.5.0, scale types were moved to their own class similar to Block fields being in Block then moving to Blocks.
The old scale type fields were deprecated, and now the contents of the new scale type fields were assigned to them.

Unfortunately this particular attempt to keep backward compat meant that on some rare occasions, depending on the order of classloading and static init, the new scale type fields hadn't been assigned their values yet at that point of the init, so they were currently null, therefore the old fields got set to null, while the new fields were properly assigned later in the static init. In those rare cases, mods using the old fields could NPE. As the issue was only present with the old fields, removing them fixed the issue, while obviously being a breaking change as well.

Does this issue occur in Fabric or in Forge? As far as I know, Fabric's modloading is single-threaded and consistent. Forge's parallel mod loading may cause a lot of issues. I suspect that it's a circular dependency issue, two classes' initialization both depend on the other, so that it may read uninitialized static values.

Pehkui should provide a static method that gets and sets the base scale immediately. The static method will be more flexible to change when similar issues occur again. I will keep the issue open as a warning.