> I did mean Lazarus. Just the text editor component feels alien. Things like block selection by default. It just doesn't work the same as any other text edit component I've ever used.

Are you sure you didn't configure it like that or something was broken? Lazarus' text editor behaves pretty much like every other text editor i've used on Windows, be it native (Notepad) or custom (Scintilla via Notepad++). Block selection only happens when you alt+click+drag (like in Notepad++ and several other editors), by default it should work the same way as any other modern editor (ie. shift+arrows should expand the selection which happens character-wise and select lines by expanding up/down - or just using the mouse to select...).

> The issue with string handling is (or was) that there seem to be different string types but that 'string' is used to describe all of them. Some of those methods require or produce ASCII, and it may be difficult to know what your problem is when you have one

As of version 3.0, plain 'String' is an alias for a mode-specific string type. For the default mode (FPC) it is 'ShortString' (the classic Turbo Pascal string), though the default mode is rarely used and only exists for backwards compatibility. When creating new projects and units, Lazarus uses the 'ObjFPC' mode, where 'String' maps to 'AnsiString' with a system-specific default codepage that you can optionally change. Note that LCL (via the LazUtils unit) does that to ensure UTF-8 on all platforms, so if you use Lazarus and LCL you can assume that 'String' means UTF-8 string. In 'Delphi' mode 'String' behaves like in 'ObjFPC' mode whereas in 'DelphiUnicode' it maps to 'UnicodeString' (which is really UTF-16 string, the name is for historical reasons).

For all practical purposes, with Lazarus and LCL you can simply use 'string' which will give you UTF-8 strings. If needed, the compiler will do any conversions for you, though most of the library has been extended to avoid any conversions. Older string stuff still exist for backwards compatibility, but you'll get warnings if you use them (the warnings will also usually tell you what to replace them with).

Note that this is new functionality introduced in Free Pascal 3.0 ~5 years ago. It is a bit more complicated than ideal, but AFAIK it was necessary to avoid breaking existing code - keep in mind that Free Pascal exists since the 90s and some people use code in it they wrote in Turbo Pascal / Delphi before FPK even started writing his compiler. Personally i only had to change a single type declaration (where i was using a string as a byte buffer - i replaced it with 'RawByteString' which is... well, a string of raw bytes :-P) in my code (which i wrote ages ago) after switching to FPC 3.0.

> The differences aren't large,but that does mean they re easy to fix. My previous employer, a Delphi shop for more than 2 decades, was unable to be compatible with Freepascal over some of these issues.

Makes sense but this isn't really Free Pascal's fault IMO, after all it is a single sided endeavor (FPC developers are trying to be compatible with Delphi but Delphi developers do not seem to have any such interest). If you need compatibility it should be something that you write your code with in mind and use functionality that exists in all the Object Pascal dialects you want to target.

> With limited source I mean that things like history will not be there, or its just a single file of part of a single file bundled up, so you're missing out on context. All makes it hard for a newbie, even for someone with some experience.

You wrote 'hidden source' not limited :-P. I'm not sure where history helps if you are not a developer of the project. In any case not everyone is on or likes GitHub or even interested in collaborative projects. Personally i use Fossil on my own PC and only release .zip extracts of my code (though the .zip extract does contain the change log at least). But i'm not interested in collaborative projects either :-P.