These examples sound like XS code exploiting undocumented or internal features, without being widely used.
I think that this really demonstrates that you have a rather idealistic view of perl core development. In reality, lots of things we change break CPAN modules, and people shout at us. And even if the module was being naughty, we're often told in no uncertain terms that because that module is a dependency for lots of other CPAN distributions we need to fix the module or roll back the perl change.
For example, if you install Moose, you pull in the following XS dependencies, some of which quite blatantly violate the XS API, or skirt its edges:
Package::Stash::XS
Params::Util
Class::Load::XS
Sub::Identify
Sub::Name
Variable::Magic
Devel::Caller
Devel::LexAlias
PadWalker
and it might be worth checking if cperl's implementation of signatures broke any official XS API
cperl's implementation is based on perl's implementation, plus my OP_SIGNATURE optimisation work, which I felt wasn't yet in a good enough state to merge into blead, but Reini decided it was ok for cperl. Other than that, the main differences are that cperl eliminates @_, and conflates signatures and prototypes.
Did it break the XS API? That depends on your point of view. For example, It added a new op (as did the perl implementation), and part of the XS API allows you to hook into the peephole optimiser. If an XS module which does additional peephole optimisation crashes because it doesn't recognise the new OP type, is that our fault or theirs? But people don't care whose fault it is if you can no longer install Moose, say - they just want sometime to fix the problem.
Dave.
