First commit fixes the unsafe class loading happening in a few load specs by moving those specs to a shared unsafe_load spec. They are run as part of load specs on Psych < 4.0.0 and as part of unsafe_load specs on Psych >= 4.0.0. I did not update the specs to make them "safe" as I am mostly just trying to get them green agan.

Quick note: there were already changes to deal with this in https://github.com/ruby/ruby/tree/master/spec/ruby, which are not sync'd here yet.

Your split seems better though, thanks!
I'll try to use that when synchronizing specs (end of the month).

Would it not be best for gem-based specs to guard on the version of the library going forward? That will allow implementations more freedom to ship newer gems in update releases.

It is also not possible to run Psych 4.0 specs on any Ruby less than 3.1 if we guard on Ruby version >=3.1. This will make Psych dev more cumbersome. Perhaps the Psych specs should move under ruby/psych?

I assume the other failures have been addressed in ruby/ruby so I won't go into them here.

Yes, guarding on the Pysch version as you did here is definitely better.
(Although I guess shipping Psych 4 in stdlib for older Rubies than 3.1 would be impractical as it could cause a lot of incompatibility)

Moving those specs to Psych could make sense, but it would need some effort to get mspec available there, integrate in CI, and still make it easy for other Ruby implementations to run those specs in their CI.
Typically specs for stdlibs trigger implementation-specific bugs, so I see it as a subset of tests to check stdlibs are working and edge cases depending on implementation details are covered.
Probably best long term to move the specs to the respective gems when possible, but I guess I won't have the time for that anytime soon.

Integrated in c6e9285 (given the conflicts rebasing or merging was too hard)
Thanks for the PR!