Murray thanks for your articles. 

But I think, should be mentioned metrics related to Write Daemon too, such as WDphase and WDQsz. Some time when our system looks works too slow, it may depends how quickly our disks can write. And I think in this case it is very usefull metrics. In my own experience I saw when in usual day our server started to work to slow in we saw that writedaemon all time was in 8 phase, and with PhyWrs we can count how many blocks were really written on a disk, and it was not so big count in that time, and so we found a problem in our storage, something related with snapshots. And when storage was reconfigured, our witedaemon continued to work as before quickly.

How about this way, just 

USER>s rs=##class(%File).FileSetFunc("c:\intersystems\")
 
USER>d rs.%Display()
Name    Type    Size    DateCreated     DateModified    ItemName
C:\InterSystems\Deltanji        D               2016-02-08 18:11:24     2016-02-08 18:21:28     Deltanji
C:\InterSystems\EMS     D               2013-10-22 10:10:17     2014-05-12 11:44:27     EMS
C:\InterSystems\Ensemble10      D               2013-01-12 09:28:38     2015-11-06 12:25:53     Ensemble10
C:\InterSystems\Ensemble14      D               2013-10-22 10:00:14     2015-11-06 12:29:29     Ensemble14

Much simplier, end returns %SQL.ClassQueryResultSet

*Func available since 2012.2

Much better If it would be possible to migrate or merge two accounts here. I have a WRC account on email from my current company, but what happens when I chnage a job. In this case I may loose access to any my content here. And I have another registration with my own email. It would be very nice if I could merge two of this accounts or something else, if I could use WRC and commonity with the same my own not corporate account.

Well, but maybe possible to get COS parser as a separate project. What I see now, that most important errors in Atelier for me now, it is Parsing errors. And such problem not only for Atelier, for any other editors which now available.  And parser as a one of the most difficult parts of editor should be done by InterSystems, they change language. While InterSystems have already opened server's  API, as a chance for any others developers to make their own editor. Next step as I think should be open Parser, or any help in support. I know exactly how difficult to write COS parser, I tried to do it for my NBStudio, and helped in writing SonarQube plugin, and last one my project it is a pygments COS parser used for GitHub. 

And finally I think, to get most support for all future editors, Java-based or JavaScript or even C#, such parser should be written on ANTLR. Now it supports not only java as a platform, JavaScript and C# supported too, and I think this parser would be used for any future editors, and Caché-developers finally gets more then one useful editor.

In our company, all developers usess their own installation of Ensemble. We develop web-application, and most of our changes we do on server-side code, and support only one version of Caché. In a team with more then one developer, but on one server much easier to disturb to others developers on this server.  And with a web-based application, you also need to change some static files, such as  JS or CSS, so in this case you can't split changes from different developers if you use any source control system. On his own server developer have a full control on development environment. 

Only in cases, where server uses only to store some data or with so small changes of server's code, and client works via network, possible to work on single server for all developers.

It's not completely right, after migrating to 2016.2 and later versions. You still can use both Atelier and Studio, even with sources in UDL format. With $system.OBJ.ExportUDL() and $system.OBJ.Load() in Studio Hook you can export and import in UDL format. So, in this case, will be much easier to migrate from Studio to Atelier in a team. But any way you should convert your sources from XML to UDL.

If you think, that really need some new language in Caché. You can add with some limitiations, if Studio already can highlight that language. Now you can do it only in Studio, Atelier does not support it. I've already wrote a short post about something like you want. And about javascript-like language which can be executed on server side, because compiles into COS, yet in russian, and it will be transleted in english some time later. In that my article, I used as an example code

// hello
console.log('Hello World!');

var name='';
read('What is your name? ', name);
println('Hello ' + name + '!');

which compiles to

;generated at 2014-05-18 20:06:36
    Write "Hello World!",!
    new name
    set name = ""
    read "What is your name? ", name,!
    Write "Hello "_ name _"!",!