The idea is interesting. There are some problems that many people have rightly put forth. One to watch out for, however, is that there is often an underlying "I don't like change" to the negativity, and you have to ignore that.

However, you do have to prove your idea a bit better. And one way to do so is to put together a useable CPAN module that does what you want, and it may need to use a Devel::* module or two. Or ten. Whatever. It gives you a playground to try your idea, get feedback, and show its usefulness. Or lack thereof.

And then, and only then, if it proves to be good, then you can bring it up to p5p to see if they would want to make it part of the actual language. And if your design takes into consideration all the concerns and shows itself to be generally useful, then maybe they'll like the idea. I've found they're less resistant to change than many of perl's users, though they are much more strict about compatibility than most, including the p5p of 8 or 10 years ago. (They've learned some harsh lessons.)

I've managed to squeak a few patches into perl. Some new features, some changed implementations, but nothing as big as this. But that has also given me the opportunity to see how these men and women operate, and, in general, I see it to be a pretty forward-looking bunch. Not all new features need to be universally useful. Heck, just look at say - it's handy, but it doesn't offer any earth-shattering benefit over print.

So, to answer your original question, try implementing it via Devel::*, and maybe that'll give you the answer ("too hard!"), or maybe it'll give you the reason to do it and offer it to p5p.