There are a couple things I'm going to be really mindful of when reviewing anything touching diffs:

Terminology. Diff operations use "tags", "i1:i2" ranges, and "j1:j2" ranges, which don't necessarily mean "lines". That's deliberate. I want to keep those i/j naming wherever possible for diffs when the code is generic. I have some old work I intend to dig up some day to add a higher-level process for diffing some kinds of non-text data.
Performance. Diff code is some of the most expensive code in the codebase. As such, I want to keep things tight where we can, avoid unnecessary work (keep checks optimized, avoid expense if it's just for typing-related benefits). Much of this code is called per-line across potentially tens of thousands of lines or more across a page of diffs, so it matters.
Regressions/changes in behavior. This code's been around a long time and there are a lot of edge cases covered. Plus we have public APIs around this. I want to avoid changing data types where it's not needed.

For reasons 2 and 3, I'm also pretty hesistant to move to a NamedTuple. Nice as it is, I ultimately don't think we should. It's easier to read and follow, but it carries a performance cost for no reason but code maintenance, and while that's not a bad reason, I think the impact on performance in diff code paths make it less of a gain. NamedTuples cost more to construct and cost more to access. Even if it's just a little, we do it a lot.

Let's move this and other non-runtime types to a TYPE_CHECKING block.

Can we order the keys in here alphabetically?

I'm trying to understand this set of changes. Bear with me.
We were conditionally normalizing, and now we always do. Looks like before, we weren't using {old,new}_encoding_list if there wasn't a class-level encoding list set, causing us to ignore what was passed in. That's fine.
However, it changes things when the case where neither is provided, forcing encoding to take place to utf-8. I'm not sure if this is right or wrong, but it's not how we had it before. But what we had before may have been broken. Trying to walk through the scenarios.
And then we're joining to strings. I don't think any of this is necessary. We certainly never did it before, and looking through this code, we never touch old, new, old_str, or new_str in the is_lists case. We only care about old_lines and new_lines. So I think we can just delete that code outright, which is good because it's an expense we don't want.
As a tidbit of historical information, at one point I was trying to keep some of this free of assuming byte strings so that we could pass higher-level objects that a Differ could understand, and then generate string results from all that. I have an ancient branch to help get some of this in shape for that, but it's stale. Not too worried about it now, but this is in part the reason we call things a and b and not old_lines and new_lines.

All diff operations use i1:i2, j1:j2, and tag as the variables. I'd like to keep these as they were wherever we can. They're technically ranges, and not specifically lines (even if we are using them as lines in this use case).

Do we have to cast to this? It'd be nice to find away around having to do this for every range of opcodes.
If we have to, we shouldn't redefine the type for every line. We should have a type alias to refer to. But it'd be nice to figure out how to avoid this entirely.

While here, can we pull self.filediff out into a local variable? We access it a lot.

This needs to be a : TypeAlias.
Can we define it near the top of the module where we normally define these?

Let's keep all this as None. It's an explicit "There are no ranges" response, and avoids creating a new object for each time (ideal since this is all called quite a lot).

The old code was this way to avoid needing to perform comparisons when we know we have our answer. Any optimizations we can get out of diff code is beneficial, since this is an expensive path.

These can be linenum1 or '' and linenum2 or ''.
But I'm not sure this matters, because in the cases where these are None, we don't make use of them in the template. So the None value is fine.

Can we move this into the TYPE_CHECKING?

convert_to_unicode should be before the get_*.

This sentence ("This compatibility ...") is missing a word, I think.

TypeAlias can live in TYPE_CHECKING.