Those apply to everyone in the jurisdiction at least, though blue laws are often widely acknowledged as being religious laws that have fallen through the cracks (even though, oddly, Christianity doesn't have any prohibitions on drinking that I know of). Still, they don't say "you can't eat bacon if you live close to a Jew and they tell you to stop." That's insane that a law is in place that says people of a certain religion can tell you what to do simply by virtue of being near you.
If you're building a dynamic or static library, we use the system allocator because Rust is "subordinate". If you're building a binary, we use jemalloc because Rust is in control and jemalloc is basically the best allocator in town. These behaviors can be manually overridden, and you can also provide your own custom global allocator (see linked RFC for details).
A Rust project using Rust libraries will generally link them in as rlibs, which is basically the Rust equivalent of an object file. rlibs just inherit whatever allocator from what they're linked into.
Rust binaries essentially never dynamically link Rust libraries, mostly for the reason Manishearth said in the sibling. The decision to have different default allocators is because there were problems linking to Rust from C libraries which used the system allocator, because Rust previously was exclusively using jemalloc.
Because Rust libraries being used in Rust projects will be statically linked currently, they will be built using jemalloc. Deploying a pure Rust project is as simple as pushing out a binary (std links to libc, so very few Rust projects are technically pure Rust, but its as good as because the system probably has libc).
Also, as a rule, you don't "free" in Rust at all, and code which defines how the memory is deallocated will be defined in the same library it was allocated in. I don't know the details of what it means when two libraries using two different allocators are interacting, but I don't think its as total a conflict as if you were to try to free a pointer with the wrong allocator's free function.
At the moment Rust doesn't have a stable ABI (aside from things you mark as C-compatible), so dynamic libaries that stick around on your system to do things aren't used much. I bet there will be a solution for this once we stabilize the ABI, though I suspect it may already be solved (I think you can tell rust to dynamically link to the allocator too, or something).
That's generally the rule in C/C++-land. If you have two shared objects/dlls linked into your program that are linked with different versions of the C++ runtime, it's not safe for an object allocated by one to be freed by the other.
I think the comparison with OpenGL is stretched. The problem with OpenGL is that it was made to a describe a limited hardware pipeline corresponding to a graphics card from the mid 90s. Manipulating this state machine is cumbersome and made more difficult by the lack of easy debugging.
Foremost, coherence is a property of tbe light and I dont see any queezing or fock states so the quantum nature is not important. Does the absoption process happen coherently with other protiens? Would this reduce the total amount of light possible to absorb as it requires rejecting the incoherent photons?
My (vague) understanding of the phenomenon being discussed is that it was discovered that, in some of the proteins involved in photosynthesis, the electrons were passed around via multiple, quantum-entangled pathways. This allows (supposedly!) better energy transmission than classical physics would.