David Heffernan

Recurring theme here is that you think that everything else is at fault when you can't achieve things that others can. Perhaps you need the curiosity to ask why this is.

Doesn't always exit with a Break

I actually don't know how that is interpreted by the compiler

This is a really good point, and very nicely expressed. Essentially the whole thing boils down to Delphi literals having ambiguity of type. Sets and arrays use the same syntax. For integers, what type is 1, how can I make sure that it is signed or unsigned, 8 bit, 16 bit etc. And 1.0, is that single or double? Why can't I state this explicitly. Other languages have these facilities, Delphi lags behind in this area.

Not sure who Dave is.... Delphi doesn't know that the type of the thing to the right of the equality operator is an array, it thinks it is a set. That's why you get the error. You might not like this, but this is just how it is right now. From the language perspective, there is clearly some magic disambiguation applied in the case of the assignment operator that isn't applied elsewhere. As Remy says, all you can do is to open a ticket. Shooting the messenger isn't going to get you anywhere. But even if the code did compile, what would you want it to do? For dynamic arrays, like other reference types, the equality operator = means reference equality. But I suspect that you would want value equality. So even if this code ever compiled, I don't think it would do what you want to do. In which case you will need to implement a method or function to perform value equality testing, and so the topic becomes somewhat moot.

I don't think your expectations are reasonable. You can't expect to mix and match Delphi versions like this. When you are ready to upgrade, do it in a coordinated and unified manner.

Try calling BringToFrontNoCap()

Hardly. It's possible, indeed common, for one person to be working on multiple branches

Use names. The performance issue you describe doesn't exist.

If the OP would explain the original motivation behind this, then we could propose proper solutions to the actual problem. This is a canonical XY question.

You can add to a counter when allocating new blocks, and decrement when deallocating, and then you find bleat if the counter is non-zero on exit

Rather than re-compile the RTL you can register a custom memory manager, which is very easy to do backed with MSHeap. And then you can add simple memory leaks on shutdown reporting. I actually do use the MS heap for my MM because I want to implement a per thread MM so that I can get decent performance on NUMA systems.

I'd definitely not be using Shortstring for that. But the asker has talked about the usage being for database. So RS232 not pertinent.

Same as always. Numerical programming. And when there exists huge amounts of code in a language, it can be hard to leave. A phenomenon well known to us Delphi programmers!

Different use cases will suit different libraries. You gave no indication of what your motivations and goals are.