The emacs community might think it's "working fine". The glibc community-- which had to forego many bugfixes and optimizations for years, solely because of emacs-- might disagree.
Oh cut me a break. The glibc "community" consists of a cabal of developers who won't fix broken for good reason and break userland for bad reason all the time, admit no wrong, and bring gaping security holes to entire platforms every couple of years. Uri Drepper was the tip of the iceberg. Nothing changed.
unexec is hairy, but it's mature, greybeard hair. It is no worse than any JIT, for starters.
The glibc community has to maintain an API at first, second improve the implementation. They were not able to improve ptmalloc2 to ptmalloc3 over many years, because they were afraid to add memory footprint for better performance. But they happily added more and more debugging hooks which made malloc even more slower for easier development.
But now they want to deprecate malloc_{g,s}et_state(), without a plan to improve ptmalloc2? They already failed.
Deprecating an API for no good reason is failure, not an improvement. It not only breaks emacs, it breaks other software also. unexec is used in perl5 also, btw. just not in the official perl5 packages.
