ThomasWinwood
This is Adam Smith's just-so story, but he was wrong - no society has ever been shown to survive on a barter economy. Anthropologists have shown that what existed before trade was the same as what exists today when trade collapses: informally held debt. Alice knows how to work leather, Bob knows how to work wood; Bob needs a pair of shoes; Alice gives Bob a pair of shoes to satisfy his need and both Alice and Bob remember that; later, when Alice's house needs repairs she knows whose shoulder to tap on.
This is "barter" in the sense that Alice's and Bob's services have been transacted through time, but you'd be moving the goalposts since you just defined barter as Alice and Bob sitting down and determining precisely how much wood-labour equates to a fixed quantity of leather-labour at the point of purchase.
If you'd like to learn more, then David Graeber's book Debt: The First 5,000 Years, is something of a standard reference on the subject. It's on the Internet Archive.
mold supports precisely one platform: x86_64 Linux. It also doesn't support linker scripts beyond what is necessary to link libc, and given the creator honestly suggested the suckless practice of editing and recompiling the source code as a possible replacement for them I have my doubts that it'll have a satisfactory replacement for, say, the things I'm currently doing. (Admittedly those things are in ARMv4T rather than x86_64, but still.)
One of the papers cited in the OP argues that a good indicator that there's something interesting about a planet is the combination of molecular oxygen and methane in its atmosphere - the former is a strong oxidiser, while the latter is a reducing gas, so there's some dynamic system producing free methane in the atmosphere.
[1]: https://blogicarian.blogspot.com/2012/10/ancient-greek-food-...
And that's before you get to platforms where most if not all games are written in C - I question whether a mere disassembly of a game like Pokemon Emerald would even be useful to anyone, whereas the pokeemerald decompilation (https://github.com/pret/pokeemerald) is clearly useful but was a heck of a lot more work to produce.
> That's a hurdle, but not an insurmountable one... unless the system didn't even support banking. (Are there any systems that didn't?)
Depends what you mean by "support". I don't think any system has a built-in mapper - they just assign a chunk of memory space to the cartridge bus, and if your game is larger than that chunk of memory space you include a mapper on the cartridge. Nintendo provided standard mappers for machines like the NES and Game Boy because it's very hard to include a substantial game in the wedge of memory space you get on the processors in those machines, whereas only one game on the Genesis/Megadrive needed one.
As such, the vibrancy of these systems relies on writing new software being a pleasant experience, and there's a limit to how pleasant that experience can be when your only choice of non-assembly language is C.
There is no globally correct choice of PRNG algorithm. If you need randomness, you should ask what kind of randomness - cryptography wants secure, Monte Carlo methods want fast, games can often benefit from N-dimensional equidistribution, etc. - and find a library specialised for that use case. A standard library function that nobody uses because there's always a better alternative elsewhere is a bad standard library function.