Oldes apparently has undertaken the task of making a build dialect/tool for his branch of Rebol3. This animated GIF makes it seem pretty slick looking in the console:
The makefiles are called ".nest" files, and here's the one in his R3 repository:
Rebol3/rebol3.nest at master · Oldes/Rebol3 · GitHub
New Ideas?
Looking past the nice colors and presentation, I don't know if any "big new ideas" jump out at me in terms of a dialect.
Preprocessor Usage
The primary thing that does jump out at me is use of a preprocessor. He has branches for #if Windows [...] that let you ask for transformations and selections in the middle of lists that are data. Less cluttered than going through and COMPOSE-ing everything, and lets you stay in the declarative domain.
Seems he's using a generic preprocessing script--not one that's specific to just this tool--and that's probably a good idea. Though now that #a is used for characters this gets a bit stickier... even if you were previously willing to sacrifice ISSUE! in your file so you could do preprocessing, you now would be sacrificing your notation for characters too.
(I should point out that with generic quoting, you do have '#a, so at least in evaluative circumstances you'd have a way to escape out of the preprocessor. It might be that if you use a preprocessor on the file, all your #... that you don't want to represent preprocessing instructions are just quoted out?)
Requiring the % on File Paths
He does use %file/path.c instead of file/path.c -- and that's a case where I've pointed out that Carl chose to use the lighter notation without the %.
I think that designing a dialect that is heavily dealing with paths as data, that if you can dodge the % then it makes it nicer to look at and edit. If you want to allow for evaluations, you would use GROUP!s or @vars or something else.
Our Nightmare Build System Is Still Upping My Game
Oldes's makefile here, and one that Giulio made...as well as Carl's original, are all a far cry from the mind-bending behemoth that is Rebmake.
Not only is Rebmake a beast, we have a bootstrap compatibility layer for morphing a several year old interpreter into a common subset to run it. It's a mind-bending challenge...the details of which I generally spare you from. 
It's nice to be reminded that we can do a lot smaller than that. But oddly enough, the challenges of working with Rebmake and the %bootstrap-shim have been forcing more and more inventions in how to make the bendiest language ever.
And Rebmake isn't overtly unreasonable; its the kind of approach that someone who's thinking in OOP terms would think if they were trying to clone CMake's object model in a 1:1 fashion. So it has been the mother of invention for complexity-taming tools...and stressing the language in areas that someone with a pure Rebol mindset wouldn't think to stress it in.
Which may explain why I'm not as urgently trying to jettison Rebmake or run on a modern Ren-C as one might think. Because forcing a new Ren-C to be able to meet an old one in the middle to run a crazy codebase is hardening the system.
But... definitely, yes, someday we're going to pitch the thing and get something lighter.
