At the same time you claim the output is factual.

Please don't do this!!!

Point is that keys' prototype expects one %hash or @array not a scalar.

And the argument must start with % or @

  DB<20> p prototype "CORE::keys"
\[%@]
  DB<21> p keys @a

  DB<22> p keys %a

  DB<23> p keys $a
Experimental keys on scalar is now forbidden at (eval 32)[c:/Strawberr
+y/perl/lib/perl5db.pl:738] line 2.
Type of arg 1 to keys must be hash or array (not scalar dereference) a
+t (eval 32)[c:/Strawberry/perl/lib/perl5db.pl:\
738] line 2, at EOF

  DB<24>
[download]

The point you should make is that there has to be exactly ONE argument!

That's why keys can't expect a LIST.

and this can't be changed with a new feature, because otherwise old code would break.

Consider

@all_keys = keys %h1, keys %h2;

which will parse like

@all_keys = keys(%h1), keys(%h2);

and collect the keys from %h1 and %h2

  DB<26> %h1=(a=>1)

  DB<27> %h2=(b=>2)

  DB<28> x @all_keys = keys %h1, keys %h2
0  'a'
1  'b'
  DB<29>
[download]

Now, if keys LIST was allowed, than the first keys would try to consume the rest of the list.

@all_keys = keys( %h1, keys(%h2) );

That's why the idea of the OP can't be implemented, without breaking backwards compatibility!