Hi Danny,
Last year, Ren-C underwent some necessary but painful transitions... as I try to reason about a working module system, and what the future of binding might look like. It means the already-not-well-documented variations from historical Rebol are even more of a minefield--I'll do what I can to improve it, but it will be slow.
But likely relevant to what you want is that I think it's going to be crucial that binding be able to let you access "binding environments" for strings. If you haven't got a chance to read this, I talk some about that:
Rebol and Scopes: Well, why Not?
So that's one heads-up I'd give you: that the best way to embed "JavaScript-like intents" inside of Ren-C may be something that is done with strings, vs. the kinds of syntax tricks you were trying.
This isn't to say that we couldn't use some experimentation in the area of Ren-C/web interoperability. @rgchris made "StyleTalk" which he explains in a video. I'd like to see us to see where things can go with that kind of thinking before bending ourselves too far into pretzels and asking if a[b]c should be its own lexical type.
Another heads up I'll give is that I've been traveling since December, and not programming much at all. Hence I'm a bit behind on the mountain of design (as well as my own pet projects...) I likely won't have the bandwidth to support anyone's new experiments that I'm not already supporting.
Though much of the current efforts are on things in the browser. If you are interested in HTML interoperability then I'd definitely encourage you to look at the ReplPad and where that is going. I'm effectively "doubling-down" on the approach of using the browser for GUI (vs. Red's strategy of writing their own code)
So if you want to be experimental in Ren-C land, the place where you'll be more likely to find support (though not promising...) is if you're trying things in the web build. It may lead you to different ideas about how to attack your problems, specifically as a mixture of JavaScript strings with Ren-C.
I'd suggest looking at JS-EVAL and JS-DO for instance, things like what @gchiu wrote just the other day:
add-content: func [
txt [text!]
][
txt: append copy txt newline
js-do ["document.getElementById('script').innerHTML +=" spell @txt]
]
That's pretty smooth language interoperability... and I'm sure it can be better! (If you read the JS-EVAL post I explain why this winds up being smarter than gluing strings together, and avoids various escaping problems.)