Note: Hash.ruby2_keywords_hash? will only recognize hashes from a ruby2_keywords method/block, or a hash explcitly marked with Hash.ruby2_keywords_hash, but e.g., not kw in def m(*args, **kw); kw; end.
I guess ruby2_keywords is used somewhere before and so it just works here (is that in RSpec code?), but it's a bit subtle.

If rspec-mocks would store positional and kwargs arguments in separate fields (only on Ruby 3+, before can't separate them reliably) then I think it would be nicer and more reliable to check.

@eregon what you are saying is right, but I'm not trying to display whether a hash was keyword args 100% of the times, I only want to display it when two hashes are identical except for the ruby2_keywords_hash?.

#1394 add this code:

        if RUBY_VERSION >= "3"
          # if both arguments end with Hashes, and if one is a keyword hash and the other is not, they don't match
          if Hash === expected_args.last && Hash === actual_args.last
            if !Hash.ruby2_keywords_hash?(actual_args.last) && Hash.ruby2_keywords_hash?(expected_args.last)
              return false
            end
          end
        end

And it's this case I want to display. So yeah, my PR only apply to 3+ like the previous PR.

Hash.ruby2_keywords_hash? still can't tell if a Hash was used as keyword arguments, except for the case we are sure the keyword arguments were passed to a ruby2_keywords method, and that Hash then arrives here, not through another call (which would remove the flag IIRC).
Is that guaranteed here that expected_hash and actual_hash come from ruby2_keywords methods?

In other words, I think the current patch might not be able to show the helpful kwargs/non-kwargs suffix for things like:

def foo(*args, **kwargs)
  ...
end

foo({a: 1})
vs
foo(a: 1)

but given this is rspec-mocks maybe it could because it might always control the definition of foo and always use ruby2_keywords there?

Is that guaranteed here that expected_hash and actual_hash come from ruby2_keywords methods?

if expected_hash == actual_hash then AFAIK yes that's the only way. Otherwise we wouldn't be printing an error.

Of course there might be some weird edge cases if you monkey patch Hash#== but...

I see, there is similar logic in https://github.com/mame/rspec-mocks/blob/865ea3a795e0e56309b823e76e3f65eff5cfa448/lib/rspec/mocks/argument_list_matcher.rb#L63-L70
I think a # See #args_match? comment would be helpful.

Also the check doesn't necessarily seem correct, it's only in one direction, because passing kwargs to a method not taking kwargs is fine: https://github.com/mame/rspec-mocks/blob/865ea3a795e0e56309b823e76e3f65eff5cfa448/lib/rspec/mocks/argument_list_matcher.rb#L66
(the comment is unfortunately outdated/not matching the code)

I'd suggest to extract the check to a separate method, then it's clear it's the same condition.

I added the RUBY_VERSION >= "3" which should solve the CI issues.

We typically add such things to rspec-support and use a self-explanatory method on RubyFeatures. Do you think it's possible to come up with a name that would explain why a special case is needed?

Hum, RubyFeatures.has_ruby2_compatibility_keywords?

Or RubyFeatures.distincts_kw_args_from_positional_hash? ?

Sure. Should I make a PR to rspec-support?

Yes, please 👍

Cosmetic: with RUBY_VERSION >= "3", I believe RSpec::Support::RubyFeatures.kw_args_supported? will always evaluate to true, so it's redundant.

Well, ruby2_keywords might go away one day (not any time soon though).

kw_args_supported? has no awareness of that.
Currently, this code expands to:

if RUBY_VERSION >= "3" && RUBY_VERSION >= '2.0.0'

It can be the other way around, expected: (options hash) + got: (keyword arguments), do we need a test case for that?

No as I said above, I don't think it's possible. If you know a way it could happen, let me know.