One of my worries (for lack of any better term) is that maybe at best it's an xkcd 927 situation and J Random Perlhaxor is now going to need to know how to do OOP TASK X / Y / Z in n+1 ways depending on the specific project/the ecosystem being used/the phase of moon.

That's a valid concern. However, Cor is designed to be part of the language itself, not an alternate object system to choose from. Thus, you could reach for Moo, Moose, Mu, Class::Std, Class::Tiny, Class::InsideOut, etc, but if Perl's built-in OO system satisfies your needs, why make your life harder aside from backwards-compatibility?

We need to end this mess where new developers ask how to do OO and the response is "first, learn how to use a CPAN client; second, pick one of the myriad OO systems on the CPAN; third, here are common installation errors; fourth, well, that OO system isn't well-known, so maybe pick my personal favorite; sixth ..."