Over time I just keep getting more convinced that it is a mistake to try to introduce non-BLOCK! source notations for internally complex data structures.
A guy I know wrote a book called "Thinking Spreadsheet" (that I offered early feedback on), where he tries to motivate techniques of working with spreadsheets that embrace the medium. He talks about how people use spreadsheets as databases:
"On a small scale, you can use spreadsheets as databases. Many people do, and several of our examples will. This is especially convenient when your data fits neatly into a small table and when you intend to interact with your data only through the spreadsheet itself. If your state has issued only 100 license plates, then a spreadsheet might be a good way to store that information."
Rebol notation is like the spreadsheet; it is supposed to be light and easy. Yet the idea of turning such a medium--a textual one--into something that is a generalized store for maps and objects and runtime representations of functions...and a whole menagerie of as-yet-untold user-defined-types...just doesn't hold water.
So the attempt in Rebol to turn all datatypes into renderable forms that might be LOAD-ed back...as part of a serialization...is I think a dead-end. The BLOCK! format makes sense as something that's a little bit better than TEXT! for serializing... but it's only a little bit.
I pointed out how I'd moved away from this with actions, and cited this counter-example carried forward from Red:
red>> append [1 2] :help-string
== [1 2 func [{Returns information about functions, values, objects, and datatypes.}
'word [any-type!]
/local ref-given? value
][
clear output-buffer
case [
...
To me, MAP! is another one of these instances where the strengths of the substrate are being undermined by trying to make it part of the source notation.
I think putting things in a MAP! (or OBJECT! for that matter) should box it up to where you can query it and get BLOCK!s back for serializing them...but you don't expect to mold them and paste them back.