Not really. You can't unload LCL in Lazarus, for hopefully obvious reasons.
I think I know what you mean, marcov. : If Lazarus is a GUI application which that build upon widgetset building block, then it shall deadly depends on LCL. Without LCL = no GUI.
Sure It is still true, but my idea could be true too.
Let say, my earlier idea of mimicking Delphi is based the fact that by using Delphi we could have 2 different TForm that are declared in 2 unit : Forms.pas + QForms.pas. It is enabled because basically Delphi := Delphi.exe + DesignerXX.bpl;
Okay I know that the QForms.pas could been eliminated by current Lazarus version.
But TUI wouldn't became one of "widgetset", because Text-User-Interface stuffs contains some properties (like left/top,width/height) that are incompatible coordinate system to be polymorph-ed with any widgetset.
From this reason, I can't use merge TUI visual component into LCL.
Another reason is it is good to have TLabel,TButton,TScrollbox for TUI rather than TTuiLabel, TTuiButton, TTuiScrollbox in
a situation that LCL is actually not exist (or not relevant by unit uses as per-form).
Well, I am using TUI here as IMHO unavoided sample case. But there will be another possibility such as TLabel,TButton,TEdit to be drag/drop inside PHP/HTML designer[1].
Hi, LAMW (android non LCL visual component) is also good to have its own TLabel,TButton,Tedit etc.
Now, back to the fact of Delphi := Delphi.exe + DesignerXX.bpl;
we can borrow that concept to split Lazarus into 2 (two) big part, one is LazarusIDE.exe and the other is LazarusDesigner.bpl (*.dll packages).
Of course the Lazarus.exe (IDE) it self will be built using LCL (widgetset / windowing stuffs), but the form-designer is freely switchable anytime among LCL and non-LCL packages.
The switch of form designer package (and classes registered contained in it) is driven by activating of a form (form designer).
This way, any FindClass function call will be only limited in designer-package, so no ambiguous class name will be happened.
So, marcov, yes Lazarus.exe will always built upon LCL (including PropertyInspector + Configuration Dialogs etc.),
but form/component designer shall not hardly LCL based only; there is must be another choice freely available when is needed.
Even current Lazarus already has mediator for non LCL visual designer ( /lazarus/examples/designnonlcl/notlcldesigner.lpk ), but it not applicable for real complex non LCL visual component implementation: something like TTabPage couldn't be implemented yet.
This way, I need a real form designer for non LCL visual component rather than simulation/painting those component's face on the canvas of LCL's form (form designer).
All of my talk above is assumed/depending on the lazarus has ability to load package from external library dynamically.
Note:
1) I am not forcing the future of "Lazarus" to have such feature above...
It can also be implemented into another new Lazarus IDE prototype.
2) I believe LCL is great, but having non LCL designer is good too.
3) loading a class from one package to be inherited inside another package is amazing, but separating packages into many library not a must for me.
So, perhaps by having one LCLDesigner.dll (which will be recompiled when synedit.pas has been modified) is enough; and then reloaded into IDE.
This situation, Lazarus.exe then is not required for recompiling.
4) I am most probably not accurate yet, since I didn't try that any further.
[1]
https://youtu.be/RIpxPvctE4E?t=31