"To Andrew Morton, instead, it looks like a kernel hack intended to work around user-space bugs, and he is not that thrilled by it."
I tend to agree. Wouldn't it be possible for a process that implements an OOM killer, to physically allocate the needed memory on startup? A proper out-of-memory handler should be limited to some (conservative) exact memory requirement.
The simplest way is to run malloc followed by a memset (for systems with overcommit). This would guarantee the pages are physically allocated or terminate/OOM at an early stage.
Now if such handler would use a kernel call or a system library that requires memory (which would be out of control of the handler's programmer), that call should simply not be made, or the said call be fixed in the kernel/library, possibly also by reserving memory for this. This behavior should also be documented. E.g. free() should never fail.