@swift-ci create

Just by a quick -debug-constraints I can see that this is a problem related to generic argument mismatch when solver is producing two solutions, one recording a generic requirement fix and the other a generic mismatch. We saw something similar to this in SR-13776 and we did a bit of investigation there #34451 just couldn't find the right solution for the problem =]
This case is slightly different, because it could be fix just increase the impact for requirement fix ... note that it may not be the ideal solution. But I suspect the core of the problem is the same (generic mismatch ambiguities involving requirement failures).

cc @xedin

Oe way we could fix that is maybe teach `diagnoseConflictingGenericArguments` to accept attempt diagnose if all solutions fixes are a FixKind::GenericArgumentsMismatch or FixKind::SkipSameTypeRequirement as well?

Looks like this is yet another consequence of an attempt to maintain subtyping relationship between collections when passed as an argument (https://github.com/apple/swift/blob/main/lib/Sema/CSBindings.cpp#L1461-L1476). Solver fails to diagnose ambiguity because collection is first attempted as `[Axis]` and then opened and re-attempted as `[$T]` where `$T` would get bound to `Axis` again. First step might be to try and restrict this behavior to only happen if there is a possible conversion/subtype relationship between the types and teach diagnostics to ignore second (duplicate) attempt.

theindigamer (JIRA User) This is a dupe of SR-14083.

Humm, so it would be try narrow the behavior to not always do this, but when it does tell diagnostics do not record any fix?

Yes, exactly. Diagnostics should recognize that this is just a duplicate type attempt (since we still have to do that for anything which might have a supertype or conversion).

Ah got it thanks Pavel!
I think I can put this on queue to work on if is not urgent, but not assigning in case someone else wants to tackle meanwhile feel free =]