Dmitrii,
Your ideas sound interesting, while I have some doubts. One usually needs speed for scientific calculations. Skipping the discussion how good ObjectScript as interpretated language fits this need, if we place upon our (even small) additional interpreter, nobody would envy our calculation speed.

Your most infamous errors list can be appended with many others, such as "DO I=1.3" error which destroyed some satellite. Besides, missing The International Date Line example is merely logical error that derives from "common" inaccurate development practice.  Alas, such development errors list is sadly long, and I doubt if physical measures mismatch has the highest rate among others.

The easier the better:

 if $data(^$Job(PID)) // then the process with PID is running...

But each method mentioned above has a potential problem: if the process with PID had finished far ago, the O/S PID counter could run a full cycle, and another Caché (IRIS) process could start with the same PID. The full solution may worth a separate article, while the simple one is: just to collect garbage often enough. To my experience, once a day is usually quite enough even on high loaded systems.

Marat, 

Maybe it's possible to build a dictionary of wrong decoding of typical words and use it for encoding guessing. E.g., a word 

לרפא
will probably be a typical one in a medicine text. Wrong decodings can be collected using a tool like this. Using pronouns, articles or prepositions as "universal" typical words can even be a better idea.

...otherwise all the gibberish lines look the same
 

While you are basically right, some euristics can help to find an answer. A line that matches a pattern: line?1(1U.L,.L,.U) is more likely encoded correctly than "camel case" one. After modifying Eduard's sample a bit: 

AutoCode
 new $namespace set $namespace="%SYS"
 Set Text = "ÍàØâàÞæØâë"
 Set Ref = ##class(Config.NLS.Locales).OpenCurrent(.Sc)
 Write "Locale name: ",Ref.Name, !!
 Do Ref.GetTables(.Tables)
 Set Key = ""
 For Set Key = $O(Tables("XLT", Key)) Quit:Key=""  line=$zcvt(Text, "I", Key) if line?1(1U.L,.L,.U) Write Key," ",line,!}
 q

we are getting (likely) correct answer without knowing a target language:

USER>d AutoCode^ztest
Locale name: yruw

LatinC Эритроциты 1

There are some other problems, e.g. system built-in tables such as UTF8 are not included, but they can be solved. Writing universal cyrillic decoder is not so easy task, but as there are some already exist in web, it's possible to write another one.

It seems that try / catch paradigm encourages one to propagate exceptions. Otherwise it's easy to get a "style mix" that looks unpleasant, something like: 

   ...
   set sc=##Class(Config.Databases).Get(pDBname,.pProp)
   if 'sc goto gDBPropQ ; more characters to type and less expressive
  
  catch ex {
   set sc=ex.AsStatus()
  }
gDBPropQ
  quit sc
}

or 

  ...
  set sc=##Class(Config.Databases).Get(pDBname,.pProp)
  if 'sc return sc ; many exit points from one method contradicts
                   ; with reasonable principles of modular coding
 catch ex {
   set sc=ex.AsStatus()
 }
 return sc
}

All this stuff is just IMHO, just an attempt to be consistent. 

Just a quick note: when errors are processed consistently, e.g. each %Status have been returned is processed with $$$TOE or $$$ThrowOnError  or $$$ThrowStatus macro, this approach seems to be excessive, and `set sc=ex.AsStatus()` is just enough. E.g. 

ClassMethod GetDBProp(pDBname, ByRef pProp, pDivide = 1) As %Status
{
  try {
   new $namespace set $namespace="%SYS"
   set sc=1/pDivide ;potential <DIVIDE>
   $$$TOE(sc, ##Class(Config.Databases).Get(pDBname,.pProp))
  catch ex {
   set sc=ex.AsStatus()
  }
  quit sc
}

For me, unexpected %objlasterror is no more than a sign of inaccurate coding, when some %Status values are not processed.

Sergey, it's great that you are writing articles for newbies, nevertheless you don't explicitly mark it. Just a quick note on your samples: ZWRITE command never returns <UNDEFINED> in IRIS, so to check the global existence one should use something like

 if '$data(^A) { write "Global ^A is UNDEFINED",! }

I'm sure that you are aware of it; just thinking of novices that should not be confused.

Stephen, agree with you, those %% can be nasty, while it's possible to avoid them in this very case:

..\bin\cache -s. -U"%SYS" <Routine/ClassMethod call>

making the command syntax very similar to Linux one. In most other cases %% are inevitable; take a look at a small brief from real CMD script: 

 call :CheckNameSpace %%%%SYS
 if %sc% equ 0 goto :help
 ...
:CheckNameSpace
 set sc=1
 If "%1" == "" goto :NameSpaceNotSet
 ...

After re-reading excellent articles referenced above, it seemed that:
1) Too low QoS value can be incompatible with VM Stun time.
2) Too high value can be inappropriate as well for some other reasons. E.g., it can postpone a failover when it's of real need when Primary crashed or isolated.
So, why not stop bothering about QoS value, and just Set No Failover during snapshot phase? Documentation describes how to do it manually, while it should be possible programmatically as well.

You may want to use some kind of print spooling to avoid the situations of monopolization such a device as printer. Take a look at CUPS; there is a brief notes how to use lp or lpr commands in Caché/IRIS: Using Pipes to Communicate with Processes.

On Windows we just used OS printer name for opening the device in Caché, and it was enough to spool the jobs to printer queue; no other tricks were needed.

To get more reliable figures on performance, we usually take the following approach (# 1):

 set nTop=1000000 // number of test repetitions
 for each test_j {
   init_counters
   for i=1:1:nTop {
      run_test_j
   }
   save_counters_for_test_j(nTop)
 }

because it introduces less extra payload and provides more precise measuring than alternative approach (#2):

 set nTop=1000000
 for i=1:1:nTop {
  for each test_j {
    init_counters
    run_test_j
    save_counters_for_test_j
  }
 }
 for each test_j {
   aggregate_counters_for_test_j(nTop)
 }