I concur the warning about security implications once you've exported terminal access via unauthorized CSP application.

This is very big, and very wide security hole! One could escalate their permissions to localsystem superuser (when you run Windows) and could do pretty much anything with your system, if you didn't properly lock all involved layers.

Putting aside legaility of this task (let assume this is all your code), your case sounds is even much more complicated: you are appranetly running newer version of an engine, with updated tokens and bytecode interpreter, but need to restore code for older version of bytecode. 

That was not frequent, but bytecode tokens map did change over the time, so you actually need 2 decompilers (for older version, and for currently used) not one. Possibility to have those is quite zero. Sorry.

[This is slightly overdue, but very welcomed change in any case!]

Did I interpret these correctly, and search improvements were mostly implemented using iFind capabilities?

There is Russian proverb for such cases "Rumors about my death is slightly exaggerated"[1] .  Be it BigData, which is declared by Gartner as dead, but is here to stay, in slightly wider form and in more scenarios, or be it MapReduce. Yes, Google marketers claim to not use it anymore, after they have moved to better/more suitable for search interfaces, and yes, in Java world Apache Hadoop is not the best MapReduce implementation nowadays, where Apache Spark is the better/more modern implementation of the same/similar concepts.

But life is more complicated than that shown to us by marketing, there are still some big players, which are still using their own C++ implementation of MapReduce in their search infrastructure - like Russian Yandex search giant. And this is big enough for me to still count it as relevant.

[1] As Eduard has pointed out that was Mark Twain who originally said "The report of my death was an exaggeration." Thanks for correction, @Eduard!

For this particular usage scenario, running x86 code thru binary translator would be not a very good idea. Raspberry Pi itself, is not very fastest ARM processor, and adding JIT oberhead would make emulation layer work extremelly slow.

OTOH, initial porting to any new hardware platform, especially for the OS which is already supported (Debian) might be quite easy (especially if you disable for a moment assembler optimizations, and compile full C kernel). [Jose might correct me here, but at least that was my impression from InterSystems times]

The problem though - whether it worth all the pain. What is the reasonable outcome any vendor could get from such habby device owner? 50¢? 5$? Ok, we are talking about educational market, thus assuming there won't be any money stream, but rather enabling ecosystem. Why we think that RaspburryPI build would not repeat GlobalDB failed experiment? Why it would be different this time (on smaller hardware market, and with less powerful hardware)

Nice catch, Daniel!

I wonder though, have you opened prodlog to change behavior of PutLine() method?

Good point - the less traffic is there, the better final result.
Although this would be not very much canonical from MapReduce point of view, but the more aggregation could be done on a single node/worker, the better for reducer.

Very good question. The push operation of our FIFO is safe, even in their "lock-free" way, because of $increment/$sequence usage and their guarantees. But pop operation is troublesome if there will be multiple workers retrieving the same head just at the same moment. 

So, yes, there is no "exactly one" guarantee, and if reduction phase will be running concurrently (it 's not yet planned such) then we have to lock each read-delete operation.

This gonna be problem for multiple node scenarios, so we will talk about this problem when we will approach remote execution and multiple nodes. Thanks for note!

Like this one?

USER>write $match("abcdeabcde", "(a|b).*(de|fg)")
USER>write $match("abcdeabcfg", "(a|b).*(de|fg)")