The original programs should be rejected, I think. Looking at your simpler example, the declaration for Foo should be rejected as ambiguous. There's no way to tell from z what a, x, or p should be. When I continue my bug sweep, I'll take a look at this.

is ambiguous. So all uses of Foo will give rise to ambiguity. But alas we do not check for ambiguous kinds.

Instead we see a "call" of Foo in the type signature

bar :: forall a (z :: F a). Foo z -> Int

At the use of Foo we intantiate k to kappa and check that F kappa is equal o the kind of z namely F a. So for the type to be well-kinded we need F kappa ~ F a. But we have no way to prove that (unless F is injective). And that's the error.

TL;DR: it's Foo that should be rejected as having an ambiguous kind.

(I have not studied the oroginal Description; just assuming that comment:6 embodies the essence.)

OK, sure. The point is—there's some definition in this program with an ambiguous kind, and AllowAmbiguousTypes is not convincing GHC to accept it. If the burden of ambiguity proof needs to be shifted to Foo instead, that's fine.

What is "this"? Rejecting the definition of Foo (which would be the effect of checking Foo's kind for ambiguity) would not typecheck more programs!

The point is that I want GHC to accept Foo (and bar). The mechanism by which I normally do so (AllowAmbiguousTypes) is failing me here.

As Simon points out, Foo has an ambiguous kind forall (a :: Type). F a -> Type. There's no way to infer the choice of a from a usage of Foo. GHC does not check for ambiguous kinds (it should, I agree), so this definition is accepted with or without AllowAmbiguousTypes. Regardless, you've specified AllowAmbiguousTypes, so accepting this conforms to your stated desires.

`
bar :: forall a (z :: F a). Foo z -> Int
`

Now we're in deep trouble. This type mentions Foo z. Accordingly, GHC must infer the invisible kind parameter to Foo. (You might say "Well, obviously it should be a!", but that would be assuming F is injective.) So GHC rejects this type signature, as it doesn't know what the invisible kind parameter to Foo should be. Note that this is not the normal ambiguity check that AllowAmbiguousTypes disables. This type has an ambiguous type variable; the type itself is not ambiguous.

Alas, this trick doesn't scale very well to the original program, since you'd need to give p as a visible argument to Sing px somehow. (It's not clear to me if even visible kind application would fix this problem.)

OK. So after these musings about AllowAmbiguousTypes, kind ambiguities, and visible kind application, I've lost track if there's actually any concrete GHC bug that's manifesting in the original program. Can this be closed, or is there something left to be done?