Great overview, I have had plenty of discussions with IT departments who don't understand that Linux, and Windows, will use available resources, especially for IO, and it is only an issue if it is persistent or unusual, and obviously if there are performance/stability issues.

Being able to provide metrics over time and proving it is "normal" usually helps.

I appreciate the comments, some things to think about.

If you have planned tables and data properly uniqueness should not be an issue and it looks like the performance consideration is unlikely to be a problem in most cases.
Being able to check the raw data easily with a standard global naming is, for me at least,  a benefit of not using the hashed names.

However, knowing these reasons is very helpful in planning and identifying those edge cases.

Is there anything else I have missed that would make this more of an issue?

Without someone providing an accepted linter you won't get everyone to agree on case etc...

My own preferences do not all match the above but if we had a defined ruleset that was easily managed and enforceable in the IDE then fine with me.

However, I think we should all be able to agree that moving away from shortened commands and names benefits code maintenance and readability plus aligns better with other languages, especially if we use classes, braces, and other "modern" objectscript styles.  Yes I know that I am showing my age, but note I avoided mentioning the "M" word 😂

Nice documentation.

Some niceties to add that I encountered, all available in the documentation link Iryna provided.

- The generated global names are often not very intuitive, you can set these yourself in the CREATE TABLE using 

%CLASSPARAMETER USEEXTENTSET = 0,
%CLASSPARAMETER DEFAULTGLOBAL = '^Packagename.Tablename';

- For concurrency checks similar to PostgreSQL you can add a version property.

CREATE TABLE ...
(
...
xmin INT,
...
)
%CLASSPARAMETER VERSIONPROPERTY = 'xmin'

Very useful.

I tend to avoid post conditionals nowadays as I long ago realised, as with your other examples, readability was far more important.

Only one I do not personally do is the Command Arguments example, I'm old and set in my ways and like using the comma 😁

Another possible mention might be "goto".

Oh, and your note on functions not being case-sensitive is only for system (intrinsic) functions.

I think the message overall is we no longer have the same memory and screen limitations and so spaced out, readable, and maintainable code is far more important than the old compacted method of writing mumps/objectscript. 

Thanks for the explanation, I assumed it worked something like that.

Do you agree with that approach though or would you prefer something more like Robert's description?

In my mind you don't create a database based on a specific file so the DAT should be swappable and retain the database settings, other database settings work that way.