Veto.
A choice to write scripts to that version of Ren-C will not receive support or bugfixes from me. Which would make it a difficult choice. It also lacks TLS 1.2.
This is partially my fault, by being unable to satisfy a finished-enough subset of the language to call "Beta/One" where experimental features are labeled thusly and be satisfied.
One has to realize though just how many concerns are in play. And it doesn't just involve the in-language stuff you see, or even the in-core stuff almost no one will ever see...but also the inter-language APIs which an in-between number of people to see.
I know it may be hard for the usermode folks to understand just how patently bad libRed is by comparison to the mechanics of libRebol. I don't know if I can get you to take my word for how important getting all this stuff right is, but it is important...
This is partially everyone else's fault, by seeming more excited (rightly or wrongly) in seeing what we can do with the web.
But I was won over as a convert. This is what reshaped my thought that a Ren-C-powered Redbol--which has desktop and browser availability--is the only answer for those who don't want to participate in the experimental portion of the "grand experiment". At least for the near term.
To make Redbol code work as expected, lib/append (or whatever) will have to act like Redbol append. So the underlying Ren-C lib of primitives will have to be lib3 or something. Conveniences in a module header for saying which Ren-C-isms you would like might be added as well.
This means you'll have access to those Ren-C-isms you find worth it. We can even bring in "approved" sets of experiments for the ones people consider truly indispensible, and honor backwards compatibility for those:
Rebol [
Title: "How we might name experimental sets"
Experiments: [17-Jan-2020 specialize adapt]
]
So if SPECIALIZE and ADAPT haven't been committed to in terms of their interfaces, then you could name a date and then the interested parties could build adapters for after when those words have been retaken for new interfaces.
So Redbol is the only option for "documented and stable", and it does exist in a form today.
It's not terribly pretty, and it contains a bunch of archaic code from what used to be called <r3-legacy>. A lot of that could be written much better with modern Ren-C.
https://github.com/metaeducation/ren-c/blob/master/scripts/redbol.reb
I mentioned I'd gotten a simple PDF out of Gabriele's PDF maker. Redbol is used to build hostilefork.com via a static site generator. With more people willing to hack on Redbol and take it on--with a GitHub issue database of its own and getting it to run through Red's test suite--it could advance.
Anyway, I've gone from seeing building old Rebol2 compatibility as being a chore to thinking of it as a demonstration of the true power of Ren-C and what makes it possible for a Rebol-like language to bend to what you want it to be. What worries me are the technical challenges of binding and such that have yet to be solved--modules never really worked.
The other option is commit to the experiment, roll with the punches, write tests and tell me where your source is and I help you keep it up to date. I can only do this for a limited number of projects which pretty much have to be of interest to a wide audience--certainly wider than just the author themselves.