FreePascal/Lazarus seem to aim mostly for the people already using its predecessors. I see little to no "evangelism". Even new niche languages like Nim or V seem to have more "momentum".
It might seem odd, but have to agree, in terms of lack of "evangelism" on the part of Object Pascal users and developers. I think this is partially because of the long "language wars" involving C/C++/C#, and continual propaganda claims by competitors that it is "dead" for the last 20 years, many might prefer to quietly indulge their preferences.
Delphi/Embarcadero does attempt to push the needle some, but of course its more for their own benefit, and arguably not as much for the language in general.
There is also the perception of what languages are favored for jobs (though freelance and independent work seems overlooked), despite that Object Pascal/Delphi is still doing quite well in the rankings (and for many years). Often floating between TIOBE's 10 to 15 rankings, and among or ahead of many notables like Go, Rust, Lua, Kotlin, D, Nim, etc... Who nobody in their right mind would claim are "dead".
One could argue that Nim had its shot, as its no spring chicken. Nim is older than Go, and has been around since 2008. So if it was going to get "the push", would think that would have already have happened.
V (vlang.io), on the other hand, comes across as a special case. Is still relatively young, so could possibly at some point make a run towards heading up the charts. It's in a sweet spot between being both a C and Go alternative, and has taken the approach of studying other languages to make itself more appealing, useful, and practical. Perhaps the sport's term, when describing a prospect, is that it has a "high ceiling" or high potential is the most appropriate.
Or companies like Microsoft finally come out with a C++ Builder alternative (C++/CX), and a couple of WinDevs starts a mutiny, brings back the C++ developers experience 20 years back to their beloved VC++ 6.0 COM development tooling, paying customers be dammed.
Microsoft are damned if they do and damned if they don't. One could just as well criticize C++/CX for being a proprietary language extension that only works with their proprietary compiler, and for not following C++'s zero overhead principle. A major selling point of C++/WinRT is that it's just standard C++. And like I've said before, thanks to modern C++, C++/WinRT is far better than libraries like ATL that were available for VC++ 6.0.
By developing and using C++/WinRT, the Windows developers are prioritizing what's best for their systems programming work, as they should. Convenient tooling for rapid application development is the job of IDE developers, like the Visual Studio team. I think one of the mistakes of Windows 8 and Windows 10 was that the Windows team tried to directly provide conveniences for high-level application developers, built into the platform. I'm glad they've backed away from that. I know VS already has some tooling for C++/WinRT. Maybe they just need to do more work on that. Personally (as someone who no longer works in the Windows org, or at Microsoft at all), I'm glad I can use C++/WinRT, which is just standard C++, with any build system I want, and presumably even with clang rather than VC.
I understand that for C++/WinRT movement, critics of paying customers left out in the cold are a bit harsh.
Well next time do a proper job, given that even ATL has better Visual Studio tooling.
The non standard extensions excuse apparently is only an issue for Microsoft compilers, as you are enjoying those clang extensions without problems.
The way management has dealt with WinRT ecosystem, it turned many of us that were hard advocates, into disgruntled developers that only wants it to implode as if it never happened.
In what concerns WinRT, "Developers, Developers, Developers" is long gone.
Short version story, a group of WinDev folks weren't happy with C++/CX and its C++/CLI extensions.
So they brought in Kenny Kerr, which was trying to create a C++ library without those extensions.
Out of that effort, C++/WinRT was born, they deprecated C++/CX (5 years ago) and told Microsoft customers to suck it up and wait for the day C++ gets reflection, because they couldn't otherwise provide the same level of tooling for C++/WinRT, as C++/CX enjoys on Visual Studio.
Nowadays they are having fun with Rust/WinRT, while every customer that has to deal with C++/WinRT enjoys editing IDL files without any VS tooling, and merging the generated C++ code manually, after every IDL change.
To the point of that even MFC has better tooling for dealing with COM.
A tiny group inside Microsoft is now happy, while all customers deal with the mess they left behind.
Pascal is an really uncomfortable language to be writing new code in 2022. In 2005 it was arguably better than most flavors of C++ but now it belongs to a museum.
But oddly, Nim never went in that direction, despite its Object Pascal roots. Have instead seen some Golang Golphers try to modify the Lazarus IDE for their purposes.