Enum member matching being case, space and also underscore insensitive like matching keyword names sounds good to me. It also ought to be so easy to do and backwards compatible that we can consider it in RF 3.2.2.

How Libdoc should show enum members is a different question and part of #3607.

This will actually be somewhat backwards incompatible as currently there could be lower and uppercase etc enum values that are different. They will be same after this change.
But I do ’t know how much trouble this might be. I would assume that not so much.

Yeah, it's possible someone would be affected by this change but those changes are pretty small compared to benefits.

The bigger question is, do we want to have such an enhancement in a patch release in the first place. A library using this functionality would then work differently with RF 3.2.1 and 3.2.2 which needed to be documented. Then again, there's the same issue between RF 3.2 and 3.3 if we do the change later.

I still think this is a good enhancement for RF 3.2.2 but if others disagree and this feature isn't needed super urgently waiting for RF 3.3 is fine as well.

Thanks to @willemvanoort for PR #3632 implementing this!

This enhancement ought to be fully backwards compatible. The reason is that the code first tries an exact match so if we have an enum like

class Example(Enum):
    FOO = 1
    foo = 2

using FOO and foo in arguments works exactly the same in different versions.

If an enum has two members with names that have same normalized form, using a non-exact version will actually be an error. For example, using argument Foo wouldn't work with the example enum above.