My guess is that this problem is a consequence of the quite delicate design of TcHsType.splitTelescopeTvs. I imagine there's a way to apply a delicate patch to the delicate algorithm to fix this, but I propose a better solution that makes this all more robust: refactor TcTyCon to store more information about user-written telescopes (that is, lists of type variables that may have dependencies) so that splitTelescopeTvs becomes trivial.

When I first wrote splitTelescopeTvs as part of the TypeInType work, I hadn't yet added TcTyCon, and I was very loathe to put surface-Haskell details about a user-written telescope into TyCon. But now that we have TcTyCons that exist only in the first stages of type-checking, it's more reasonable to put in more surface-Haskell information. I think this refactoring would be fairly straightforward, but I'm afraid I haven't the time to do it myself. Happy to advise if you (for any value of "you") wish to take this on. Alternatively, if you want to figure out how to fix this particular problem without doing the larger refactor, I'm happy to look at that, too.

getInitialKinds produces the kind of a tycon from a LHsQTyVars. kcTyClTyVars and tcTyClTyVars then have to match up the bits in the LHsQTyVars with this produced kind, so that we know, for example, which kind variables are mentioned explicitly in the type and which aren't (affecting visibility). That is the point of splitTelescopeTvs, simply to find the correspondence between the LHsQTyVars and the kind of the tycon. With TcTyCon, we can just store this correspondence -- basically, storing in the TcTyCon exactly what kcTyClTyVars and tcTyClTyVars need to function.