Beaucoup de développeurs Delphi espéraient simplement avoir à recompiler leur application Windows avec Kylix pour en faire de vraies applications Linux. Évidemment, il n'en était rien, et créer un projet multiplate-forme passait obligatoirement par l'abandon de la VCL au profit de la CLX (sans parler évidemment de la suppression de tout code invoquant directement un API Windows). Cette nécessité de réécriture fut un premier frein au développement de cette bibliothèque.
De plus, la CLX a souffert du manque d'expérience des développeurs de Borland vis-à-vis de Linux. Par exemple, certaines déclarations d'objets de synchronisation ou de communication interprocessus étaient fausses et il a fallu plusieurs versions successives avant que les bugs soient (partiellement) corrigées. Aujourd'hui encore, de nombreuses améliorations sont en proposition et incluses sous la forme de patchs non officiels par des développeurs indépendants.
La CLX obligeait également la distribution de plusieurs bibliothèques propres à Borland, notamment pour l'interfaçage avec Qt. Le déploiement d'applications graphiques sous Linux n'était pas trivial et souvent problématique. L'aspect non « natif » d'une application Qt sous Windows fut aussi un frein au développement de cette bibliothèque.
Avec l'abandon de Kylix par Borland, la CLX n'est plus une solution d'actualité. Il aurait fallu un effort constant d'adaptation au fur et à mesure des nouvelles versions de la libc et de Qt, ainsi qu'un réel investissement dans la correction de bugs résidents en particulier dans la VisualCLX : par conséquent seul subsiste la VCL comme framework de développement sous Delphi et C++Builder.
