Nick,
May I ask you: where did this magic number (201772B865) come from?

Whenever I return "useful" value from a method I regret it afterward. E.g.

set square=##class(mathCls).squareTriangle(a, b, c)

What if something went wrong, e.g. actual parameters (a, b, c) are invalid? I need some sign of it, so I'm forced to add some kind of status code. Let it be of %Status type. So, the caller's code is getting more complex:

set square=##class(mathCls).squareTriangle(a, b, c, .sc) if $$$ISERR(sc) $$$ThrowStatus(sc)

In contrast, when the status code is returned, it is not getting significantly complex:

$$$TOE(sc,##class(mathCls).squareTriangle(a, b, c, .square))

Besides, if each method returns status (even when it is always $$$OK), the whole code is looking more consistent and does not need modification if some of its methods get new behavior and able to return some error status as well. 

Doing finalization like this you are rejecting your previous point to use $$$qoe(...).

Acting this way, you are just quitting your method on error. What if your method needs finalization?

Both approaches have been discussed above (try/catch or $ztrap/$etrap) allow it easily.

Evgeny,
Is it a question: try/catch (or another way of error handling) or %Status? If we try to follow some solid design principles, each method should perform only one function, have only one way to exit from, and should inform the caller whether it succeded. So, we should use both. Extending your sample: 

ClassMethod solid1(parameter, ...) as %Status
{
  set sc=$$$OK
  try {
     $$$TOE(sc,##class(x.y).a())
     $$$TOE(sc,##class(x.y).b())
     ...
     $$$TOE(sc,obj.NormalMethod(parameter))
     ...
  } catch e {
     // error handling
     set sc=e.AsStatus()
  }
  // finally... common finalization for both (good or bad) cases
  return sc
}

One could write it in another fashion, e.g.

ClassMethod solid2(parameter, ...) as %Status
{
  set sc=$$$OK
  new $estack,$etrap
  set $etrap="if $estack=0 goto errProc"
  set sc=##class(x.y).a()) if 'sc goto solid2Q
  set sc=##class(x.y).b()) if 'sc goto solid2Q
  ...
  set sc=obj.NormalMethod(parameter) if 'sc goto solid2Q
  ...
solid2Q
  // finally... common finalization for both (good or bad) cases
  return sc

errProc // common error handler
  // error handling
  set sc=$$$ERROR(5001,"solid2 failed: "_$ze)
  goto solid2Q
}

Which version is better? If we don't need individual error handling of ##class(x.y).a(), ##class(x.y).b(), etc calls, I'd prefer solid1. Otherwise, solid2 seems to be more flexible: it's easy to add some extra processing of each call return. To achieve the same flexibility in solid1, we are to cover each call in an individual try-catch pair, making the coding style too heavy.

 ...as much as possible avoid the need to use subscript level mapping (SLM) to manage growth of a single global across multiple databases. 

Ray, may I ask you: why should we avoid it?

Several ##class can be eliminated, making the code shorter and readable writable better:

ClassMethod CRUDUser(id, name) As %String
{
  q:'$d(name) "Name required" s x=$classmethod("Data.User",$s($g(id)="":"%New",1:"%OpenId"),$g(id)) q:'x "User not found"
  s x.Name=name q $s(x.%Save()=1:"User saved",1:"Error saving")
}

Daniel,
Not talking about whether $zerror/$ztrap is good or bad, false positives and negatives can be avoided if use it right way. The well-known pattern is as follows:

rouA
  set $ze="",$zt="rouAerr"
  ...
  set sc=$$funB() if 'sc quit sc
  ...
  quit sc
rouAerr
  set $zt="" ; that's of great importance!
  set sc=$$$ERROR(5002,$ze) ; just a sample of processing $ze...
  quit sc

funB()
  set $ze="",$zt="funBerr" ; while not neccessary, local $ztrap can be defined
  ...
  quit sc
funBerr
  set $zt=""
  set sc=$$$ERROR(5002,$ze)
  quit sc

I am not putting my hopes on GBLOCKCOPY  due to its limitations

This precaution sounds strange in your context: if you are simply copying a set of globals that are actively being modified, you will get an unpredictable result nevertheless the utility you choose. To make a consistent copy, one should apply journal records or (if copying to another Cache instance) use some cross-system technique, such as Mirroring or Shadowing, while both require Multi-Server cache.key.

If you tell us more about the task you are trying to solve, we'd advise you better.

Public recognition by developer level

Other vendors from your list have some kind of developer certification as well. E.g., https://docs.microsoft.com/en-us/learn/certifications/
Or you meant something else, didn't you?

it is a part of admin-panel of our web-application

I guessed it was not ad hoc writing ;)

Even with some universal tool like your admin panel, you can generate only those tasks which code you preliminary prepared with d code.Write() commands. The reasons of preparing code this way in this very case are still unclear for me: I can hardly imagine extra functionality you can add to the traditional approach demonstrated in Evgeny's reply.

Alexandr,

why did you prefer generating the task class instead of just writing it in some text editor? Looks like overkill for such a small task.

Please look at
https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?APP=1&CLASSNAME=%25SYSTEM.License
query ConnectionAppList()

The data source is the license server. The license server maintains counts of ISC.Appname license sections but does not manage other application license sections. Usage of other license sections can be examined with the ApplicationUserList query which returns license use for all applications on the current Cache instance.

 "...other application license sections" is just our case, so ISC licence server can't help much.

Eduard,

If you are still interested: Application licensing doesn't support distributed license accounting; it was the stopper for us as our largest customer is running Cache based application (SP.ARM's HIS qMS) in distributed environment.
 

I'd like cm that stands for community. Everybody knows that we are all developers here, so this is not of great need to be reminded. Just IMHO :)