It is correct to say that LXC and LXD are different, although the latter (LXD) rests on LXC.
To easily distinguish the 2 systems:
LXD: for image management, there is a single command called ‘lxc’ which accepts parameters (the one I am using now in my tests)
LXC: for image management, it has a series of commands starting with ‘lxc-’, such as ‘lxc-create’, ‘lxc-attach’ and so on
Trying to sort things out for my own edification as much as anything else...
So LXD is on top of LXC, rather than the two being in some way in competition or one being a fork of the other.
Docker is at more or less the same level as LXD, although I don't believe it relies on LXC these days. I've explored this for things like FPGA development and have come up against security features which I had to relax before I could e.g. get USB port access.
Snap, AppImage etc. are at more or less the same level as Docker. I'm using these to encapsulate things like Ghidra and FreeCAD.
runc is at a lower level, looking at my desktop system I think it was pulled in as part of the basic Debian system.
Virtualisation (Qemu, KVM etc.) and paravirtualisation (UML) are of course completely distinct.
I was tempted to just stick LXC on a system until I got snared by the runc rabbithole, but I'd rather not get too deeply into it right now since I'm trying to do a hardware repair (no schematic, no silkscreened component labels...). Maybe later.
I'd note that since I routinely SSH into Docker containers it would probably be possible to have the Lazarus IDE on the host but gdbserver (accessed via a socket) in the guest/container. However in almost all cases it would be better to have the whole IDE in the guest, with either VNC or X11 piped through SSH. I'm not sure whether that has any direct relevance to your attempts to find out what LXD is doing ... ... if I had to recommend a course of action I'd suggest using TProcess as I mentioned earlier.
MarkMLl