Thanks! Some comments below. I haven't looked in detail at the implementation yet, just at docs and the behaviour of the rule as indicated by the snapshots.

I don't think this should be a pyupgrade rule, since all our existing pyupgrade rules are modernisation/stylistic rules. This rule is different, since it detects (and fixes) behaviour that would cause the code to raise an exception at runtime. I understand that you want to share the code being used in the existing pyugprade PEP-695 rules, but we could always move those utilities to somewhere else in the ruff_linter crate, where it could be accessed by both the pyupgrade rules and this rule

I haven't reviewed the code in detail yet either, but it looks a little longer than I expected. I might be oversimplifying things, but can we pretty much reuse the logic from the UP046 class rule and just perform an Edit::insertion at the end of type parameter list instead of writing a full list? That would save you the effort of duplicating all the checks from UP046 (like the default kwarg that Alex pointed out) and converting existing TypeParams to TypeVars only to write them back into TypeParams. This would also lose you any deduplication it looks like you're doing with is_existing_param_of_same_class, but the incoming code was a real mess if it had mixed type variables with duplicates 😆

Thanks for this! It looks good to me overall besides a couple of nits and a bigger question about reusing the TypeVarReferenceVisitor.

Thanks for your work on this. I especially appreciate the thorough test fixtures. I think I'll need to steal some of those for UP046 and UP047, if you don't get to them first 🙂

I'd like to see my latest comments addressed, but they're mostly nits so I'm still happy to approve.

Thank you -- this overall looks great now! And I'll second @ntBre that your tests are excellent. I just have a few coding nits:

Nice!