The type string containing iterator just can't be the right condition here. What's the problem this is trying to solve?

For statements using SwigValueWrapper with an iterator type as its template argument, e.g.

SwigValueWrapper< std::vector< enum EnumVector::numbers >::reverse_iterator > result;

MSVC (version 14.41) requires a typename prefix to compile, like this:

SwigValueWrapper< typename std::vector< enum EnumVector::numbers >::reverse_iterator > result;

Is it a problem with iterators only?
Perhaps a more strict matching?
Like '::iterator' or '::[a-z]+_iterator' regular expression?

Looking here:
https://en.cppreference.com/w/cpp/iterator#Iterator_adaptors

There are many iterator types:
Some follow [a-z_]+_iterator.
But some are shorten like
inserter for insert_iterator

If we need to add this to all iterators type, seems we need a dictionary.

Did you find any document from Microsoft on the last VC++ change that require typename?

Looking on
https://en.cppreference.com/w/cpp/keyword/typename
and
https://learn.microsoft.com/en-gb/cpp/cpp/typename

It is more than iterators.
Seems this fix need a bigger change.

1. What changed in VC++ that suddenly need the typename, do they have a configuration/flag that control this.
2. If we do wish to add typename we need to follow the standard and do that in all cases, not just an ad-hoc fixing of the iterators we found.

It won't be anything to do with iterators as such, and certainly not with types containing the substring iterator, so please let's not go further down the rabbit hole of trying to conditionalise this on the type name.

There's something about these types that requires this, and we need to work out what it actually is (I'm guessing you tried always including the typename disambiguator but that breaks some other cases?)

It's unclear to me if the new MSVC is buggy here or if other compilers (including older MSVC) are just lenient in coping without the typename disambiguator, but I guess even if MSVC is buggy we may want to work around it.

If this isn't an MSVC bug then Microsoft's attitude to compatibility seems frustratingly inconsistent - they don't declare __cplusplus correctly by default because they worry it will break stuff (despite not declaring it correctly breaking stuff for people who are not working in a Microsoft-only bubble) yet they seem happy to break stuff like this with only a minor version bump.