Ruby master - Bug #16701 (Rejected): Odd output when using _1 ("ordinary parameter is defined")

I have tried to reproduce this issue into a small script, so first the code, to ease
copy/pasting (don't mind the quality; I encountered this in a larger script, so I
just tried to narrow this down):

@hash = {}
@hash['abc'] = { :a=>1, :b=>2, :c=>3}
@hash['def'] = { :d=>1, :e=>2, :f=>3}

def foobar(i = hash)
  i.each {|first_argument, second_argument|
    pp _1
    pp second_argument
  }
end

foobar

If you run the above code, the following output is given by ruby:

foobar.rb:7: ordinary parameter is defined

I am a bit confused as to why this is given. So perhaps this is not a
bug after all, because it may be that named arguments can only be used if
there is no explicit name given to them, such as in the above script done
via |first_argument.

So this may not be a bug, but instead a wanted feature/specification. But if
I then understand this correctly then it also disallows the use of
named parameters while being able to use pp _1 if we already gave a
name to the arguments. This then limits the functionality of pp _1 and I
am not entirely sure why this must be the case.

I like giving explicit names, but in the very middle of writing code, I'd
like to also be able to just quickly do e. g. "pp _1", often because
I may forget the name of hash keys and values or nested hashes. So
now I am a bit confused. Perhaps this is a bug, perhaps not. I have no
idea, so I report this here anyway.

If this is not a bug, though, then this artificially limits the usefulness
of _1 _2 since they are not allowed when we give an explicit name, which
I used to think was possible (I may have missed the full specification).

In such a situation I would then be forced to either use _1 _2
without an explicit name of the block parameters, or stick to
the block parameters instead. Since my primary use case was more to use
_1 _2 etc ... quickly, as means to be faster/shorter, that would mean
that I'd only use explicit names for block parameters and skip _1 completely,
which is also ok - I was just confused about the above behaviour, so I will
report this here anyway.