prefix type-level cons can't be parsed
Whereas other type operators (whether used as type families or used as data constructors) can be safely used in a prefix form, only the type-level cons of the built-in list kind can't be used in a prefix form.
It really is a problem because we don't have any means to express the type-level cons itself in source code. This for example prevents us from writing a generic type-level foldr that takes the built-in list and other similar data types alike.
In a ghci:
> :set -XDataKinds -XTypeOperators > data Listy a = a ::: Listy a | Nily > :kind! (:::) (:::) :: k -> Listy k -> Listy k = forall (k :: BOX). (':::) > :kind! (:) <interactive>:1:2: parse error on input ‘:’