Discarded options and why

Over the course of the stage0 project we have come across thousands of recommendations and very little actual value. There ended up being major categories into which these recommendations fall.

1) Depends on a bigger and more complex language than the functionality it provides.

Usually this is obvious with projects such as lis.py

but more often than not, its complexity is hidden behind layers of abstraction you don't realize are there.

The most perfect example of this is: jones FORTH

at first glance it looks like a full FORTH that only depends on basic assembly, until you look closer and realize it is leveraging GCC's macro assembly and not just the simple parts of that either.

For those that are not familiar, GCC's macro assembly is actually richer and more complex than the entire FORTH language.
This is the primary reason scm-go was rejected

2) Depends on a complex operating system and runtimes.

If your "Low level bootstrap" program depends on X11 and glibc to work, you are not a low level bootstrap.
My personal favorite example is amber

congrats, you managed to bootstrap smalltalk on top of javascript but what you have done can not be used as JS realistically requires a C (or worse: C++) compiler and thus does not help in solving the bootstrap of GCC problem.

3) Can't figure out how to implement the required functionality without already having that functionality

An extremely common case in languages such as lisp, where there are literally ZERO examples of proper macro functionality

that is 1) Written by a human with the intent of being human editable and 2) Provides the lazy evaluation required for proper macros.

Even Gnu Guile fails on this count (they auto-generate the lisp code needed to bootstrap the macro functionality)
Smalltalks are actually far far worse at this, such much so that I refuse to even consider implementing a smalltalk core.

4) This language is a magic solution to all your problems

3 groups love to say that their language (FORTH, Lisp and Smalltalk) that once you implement their core, everything else immediately

and with no work instantly can be used.

We even have massive projects with boatloads of work of incredibly intelligent people proving the exact opposite.
To much of the frustration of Janneke and every other lisp programmer who ever looked at the topic, C compilers are really really hard to do correctly even in lisp.
To the numerous jokes that are referred to as lisp interpreters written in FORTH (Yes it was very clever of you to get it working) that end up being more complicated and harder to maintain than a lisp interpreter written in assembly (can you say garbage collection?).
Or a language no one is willing to promise to work in (primary reason many languages are rejected, including interesting things such as: pascal-S and anything involving Oberon
There is no magic in bootstrapping, just hard work performed by smart people over a long period of time.

5) My idea is so cool, you should spend months working on it

These include such brilliant ideas as:
Write a Haskell in assembly from scratch (it'll only take 15 years with a team of 20 full time developers)
Rewrite your lisp in FORTH (that'll only take 17 months and provide a net negative benefit)
Add virtual hard drives to the VM and port Linux/GCC (are you freaking kidding me???)
Write a javascript interpreter in assembly from scratch, that'll help you get more developers (What drugs are you on?)
Implement language X and you'll get a boatload of more developers (Provides me their names and contact information and I'll consider it)
anything that involves brainfuck such as jrp and yabfc violate this very hard
Use a harder to bootstrap language first ( Why not implement go instead of C? )
Implement a language no one knows Edison, Om, etc and are evolutionary dead ends.

6) Why are you doing the heavy lifting in a VM?

The reason why stage0 has a simple and easy to implement VM at its core is to allow cross-platform verification and simplify the universal bootstrap process.
It also forces certain properties that prevent cheating in the bootstrap and eliminate Operating systems, runtimes and any local functionality from interacting with the bootstrap in anyway.
People love to point out the bcompiler but they all fail to realize it only works on x86 processors, it violates the x86 spec (aka not all x86 virtual machines will behave correctly given its objects [Even some legacy cpus can't run it]), it requires a FULL Operating system to work, and it's net result is terrible (If you don't believe me, try to write a serious program in B; I'll wait).

7) Use this thing that effectively doesn't exist yet.

Usually related to impressive looking projects that never pan out.
Hence why qcc is shoved here until it actually delivers something worth looking at.

8) Take these binary blob patches

Go fuck yourself

What will actually be useful:

A 5 line patch that moves the bootstrap forward an inch
A paragraph written helping people get started with stage0