First of all, you'd need to somehow make the Free Pascal and whatever C++ you choose to talk to each other, the C++ compiler to be able to instantiate Free Pascal classes (so you can use LCL) and the Free Pascal linker (in the platforms where it is used) to be able to link against C++ objects. Also it would need the C++ compiler to take into account the minute details of Free Pascal's semantics (e.g. in C/C++ it is undefined behavior to dereference a NULL object, but in Free Pascal it is perfectly valid - it'll just do whatever the underlying system does when someone tries to access memory at address 0 - so the C/C++ compiler should not assume that never happens).
This is the hardest part, but the second hardest part isn't that easy either: you'd also need to extend CodeTools (the framework that Lazarus uses to parse and maintain an in-memory view of the source code you are editing, the units it uses and their structure and basically keep a somewhat mirrored - but mutable - view of what the compiler would see, plus the extra stuff an IDE needs like the ability to perform queries to find symbols, declarations, etc and manipulations for refactoring) to understand and work with C++ code, so that IDE functionality for updating the code when you modify a form, create an event handler, syntax and word completion, code completion (e.g. declaring a property and automatically creating the backing field and setter method or implementing abstract/virtual methods from a superclass - that in this case might be in Free Pascal instead of C++), etc will work.
Note that Embarcadero (who develop Delphi and C++ Builder) did the compiler part of the above using Clang for their C++ Builder, but since Clang doesn't require sharing the changes, that effort was basically lost (only usable by those who are still stuck using Embarcadero products, until the project inevitably dies as C++ Builder was far less popular than Delphi), so anyone who wouldn't like to do something similar with Lazarus would have to start from scratch - an unnecessary waste of time thanks to Clang choosing a permissive license.
In practice however i do not think this will happen because it'll need coordination between several teams - and each team to care about the others. For example, Embarcadero who did that with Clang are now stuck with an ancient version of it because of their modification. For it to be done right, it would need the Free Pascal developers to cooperate with the Clang developers to not break each others' code and for the Clang developers to accept the extensions the Free Pascal developers introduce to support the extra functionality that interfacing with Free Pascal needs.
It would be useful to create tools for existing codebases. For example ~10 years ago when i worked at a game company, we were considering C++ Builder to create the tools for the engine because we could use the engine libraries directly (the engine was really a collection of many small libraries). However that idea was abandoned because C++ Builder at the time had very bad support for C++ (a few years ago they switched to Clang and modified it to use their C++ extensions, but that was too little too late - and AFAIK it wasn't 100% compatible with the previous compiler).
Actually many C++ devs are ex-Turbo Pascal, Delphi and C++ Builder users.
It just felt natural to use both languages.
C++ was the welcoming home that we never taken C for, thanks to offering language features that we could use to for safer applications, and more developer friendly abstractions.
If you are fine with COM and staying with Windows only, Free Pascal has native support for COM interfaces and Lazarus can generate wrapper units for ActiveX controls so that you can use them in a form like anything else.
However i think it might be a better idea to just use a plain old C interface (c2pas can help to automate this if you want to create a hybrid C and Free Pascal project).
I really miss those millenial usenet discussions about whether if you should be trying to send large amounts of data over flaky 56kbps connections (at best) via TCP instead of using CORBA2 because it was slow and required code to adapt existing systems. Delphi already had remote objects, data providers (served via SOAP) and database connections and they actually worked well. In the meantime, microsoft and yahoo invented their own binary chat protocols which worked reliably and scaled to hundreds of thousands of users and everyone was jealous.
The top comment was about C++ support. With LoadLibrary you can easily interface with C functions but not with C++ classes. That's why a lot of C++ code still exposes a C interface if it's used from another language. COM works too but that adds other problems.
