" Delphi didn't have to since it only had to work with Windows and only with their own libraries"
Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks.
I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that
AFAIK Delphi on non-Windows is very different than Delphi on Windows, exactly because of issues (and AFAIK it even used FPC for a little for non-Windows targets, though this was eventually replaced with their own code when they started using LLVM). They were perfectly fine with having differences between platforms at the core level, however this wasn't what FPC developers or Lazarus developers wanted - in general they try to have things operate as similar to all OSes as possible and they also support way more targets than Delphi, which complicates things.
In any case i was referring to Delphi in general from the start. Delphi had support for dynamic packages since version 1, but for decades they only supported Windows. FPC on the other hand had support for multiple OSes before even version 1.0 was released.
TBH i do not remember the exact details, but IIRC it had to do with memory management, symbol resolution and RTTI support across DLLs (e.g. being able to do something like "Foo is BarClass" in DLL A, Foo is an object instantiated in DLL B with a class that is only available on that DLL B but descends from a class defined in the main program whereas BarClass is a variable holding a virtual class defined in DLL C that also descends from the same class - essentially tying to merge in RTTIs from different AOT compiled modules where none has a complete view).
And of course the fact that it was a low priority issue since there wasn't any major practical drawback (personally the only issue i had was that i couldn't share the RTL and LCL between executables that i'd otherwise package together, meaning that the produced executables would take more disk space than necessary since each executable is having their own copy of the RTL and LCL instead of using them from a shared object/DLL).
Yeah, Delphi is still trying to find its compass when dealing with cross-platform. Intentions are good, just execution lacks. Problem is currently none of them (either Delphi nor Lazarus/FPC) are a good fit overall. Each solves problems on different platforms differently while having other problems that are non-existing for the other.
I do have fun playing with them though, trying to learn each what quirks lurks around. I mean one example is above I said - Delphi can target ARM if it's Android, but can't target ARM if it's Debian. So I can run on RPI something Delphi cooked if I have Android there, but if I have Raspbian I can't. Same hardware, different OS, such a hard nut to crack :). While if it's Intel and you have Linux, guess what - Delphi owns it.
So for now I am switching between IDE's/Frameworks all depending on availability of technology and most importantly what client(s) want.
Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks.
I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that