Thank you very much for the reasoning. Will review it a bit later - I am short in time rn.
For now I want to quickly share how I got around this and maybe(not for sure) convinced myself that the issue in question isn't really that important and can be bypassed. Which... is great!
By playing around with syntax I realized you can use a protocol with associatedtype or Self requirements as a constraint and take advantage of the where clause to tie the associatedtype parameters to the parameters of an enclosing generic class:
protocol P {
associatedtype Type1
associatedtype Type2
...
}
class A<T, U> {
....
func foo<R: P>(_ arg: R) where R.Type1 == T, R.Type2 == U {...}
}
This really cheered me up.
Not true generics of course, otherwise it would be this way:
func foo<A, B>(_ arg: P<A, B>) {...}
which can be simulated* with the following (* because T below has to ultimately be concrete(non-existential))
func foo<T: P, U, R>(_ arg: T) where T.Type1 == U, T.Type2 == R {...}
Yet being able to use protocols with associatedtype requirements this way helped me out, namely spared me from declaring multiple protocols for specific types and thus declaring multiple classes for them as well. Now everything is encapsulated in a single generic class.