No, it's very common. It's widely used in garbage collectors (instead of write barriers) and JIT compilers (for changing the code and also just for halting code execution) among other places. It's so common that userfaultfd was added as a better approach:
http://man7.org/linux/man-pages/man2/userfaultfd.2.html…
Firefox also has a custom linker using this. On Android, the traditional officially supported approach to native libraries has them stored compressed in the apk and automatically extracted by the package manager to a library directory not writable by the application.
The more modern officially supported approach leaves them uncompressed in the apk (which only impacts installed size, since apk downloads should be compressed due to this approach for various kinds of resources, etc.) and aligned to page size. The linker knows how to map those.
Firefox stores the libraries compressed using a path not extracted as native libraries by the package manager. Instead, they manually extract / decompress the libraries. On low-memory ones, they put them in app data. On high-memory ones, they extract them directly into memory.
The insane part is that they use some nasty hacks to perform this extraction / decompression lazily. They catch segmentation faults from attempts to use the libraries and then map them in to those locations on demand, either paged from app data (low mem) or as dirty pages...
Chromium takes the officially supported approach of having them stored aligned / uncompressed in the apk and mapped directly from there. In fact, that was originally created for Chromium in a custom "crazy_linker" (doesn't deserve that name when you look at what Firefox does).