I want to be clear here that this is actually the biggest part of the issue with this. I don’t think this is something that was well considered when it was cut, because it becomes quite obvious that the lack of use cases was because it wasn’t supported, so nobody was typing those things. The authors not seeing the use case is the problem here. It doesn’t take much exploration to realize this would be needed in some cases, see the very trivial examples above.
The type system is being bolted onto the language, and the gradual nature means people need to look at not only the things they are making now, but how this may interact with other things and things that haven’t been typable so far. I have no reason to think the authors did a good job of that here.
There are a lot of other cases like this historically (such as paramspec only supporting uses that use both args and kwargs), there are also people favoring extremes of consistency for type checkers over users even in current discussions trying to clarify behavior (see: What are the subtyping rules for tuple[T, ...]?) or the fact that we now have a whole thing with StrictTypeGuards. It’s also come up with people preemptively wanting worse behavior for users in intersections to increase the chance type checker maintainers won’t push back against it I’ve been pushing back on this where I see it and I know there’s a use case for more, but it’s happening so much with typing that I’m having trouble even staying motivated for my own use. It’s at the point where it would be less effort spent to rewrite in other languages, than to work for a better experience in python, and the effort would be entirely technical, rather than having people realize technical decisions have social impacts beyond what they personally are effected by.