Inofficially CBOR was designed as a protocol base for CoRE-related protocols. CoRE stands for Constrained RESTful Environments and is an alternative for HTTP in restricted environments like micro controllers. See also https://ietf.org/wg/core/charter/
Just take a look at the Appendix D of RFC7049, where they present reference implementations in C and Python for half-width float decoding: http://tools.ietf.org/html/rfc7049#appendix-D
The approach of Bedrock Linux is very interesting. It makes use of Linux-specific features like bind mounts and tries to unify several linux distributions into one meta-distribution, which gives the framework for the multi-distribution operations. They could also use namespaces for a more strict separation of clients, but that's a detail.
The idea to move completely to musl is a little bit utopistic, because musl libc is in a very early phase if you want to compile any piece of software of the base system with it. It's mostly C99/C11 and POSIX compilant, but there are several GNU-specific libraries missing, and in a world which uses GNU userland on Linux it's not simple to overcome that limitation.
The mentioned /etc problem seems to be the same problem as solved by ip-netns(8). Take a look at the source if you need further information, it's based on other bind mounts.
But I don't think Bedrock Linux is the next-generation approach for Linux distributions, or rather software distributions in general, though they don't claim that. I'm working on my own Linux distribution since about a year and it's based completely on a ports tree, as known from FreeBSD, but with a simpler code base and simpler Makefiles. At the moment, I'm trying to create a stable commit, which will build without issues in several configurations, but that's hard work, especially because Linux or rather the Linux userland is mostly a ghetto™ (you won't get information about much low-level software).
But I think, as you should noticed, that Bedrock Linux has a right to exist, but it won't be the next-generation approach.
The fact that returning memory to the Kernel is hard is supported by the circumstance, that most allocators will use brk/sbrk to resize the data segment of the executing process to allocate memory, at least if they shall allocate few memory.
The other fact, that allocators have to lock global data structures is also not true. Most modern operating systems supports thread-local storage and therefore you don't need locking because you can keep much per-threads allocators, and only if you want to release memory of a foreign thread you have to lock (but that's also bad practice in most cases).
Therefore, this article is great if your horizon end at the default allocators tcmalloc, ptmalloc and jemalloc, but the reality is much more complex. The fact that such a thing doesn't exists isn't founded in the fact that it's hard to implement, it's founded in the fact that there is no need for such an allocator, because most well-written software will allocate large chunks of memory.
That library is in many ways deprecated and broken: At first, it uses only old-style classes because it doesn't inherits object explicitly. Furthermore, it uses print in a method; it would be more "Pythonic" to return a str object, which was formatted using str.format.
I think the future is Python 3, and new implementations in Python 2 syntax are simply unneccessary. I would suggest the usage of Python-3-style syntax, which is also valid in Python 2.7 (which isn't hard).
That's simply not true. There is the rule, that NULL must be equal to (void *)0. I had also several discussions about that topic, but it's part of at least C99 and C11.