@BlackATTR feels that being able to write code as operation(arg) with no space is critical to the SQL dialect. While we haven't expressly prohibited that yet, it is lossy:
>> [operation(arg)]
== [operation (arg)]
I just noticed another case of tight syntax with a %rebol-dom.r script where @Danny is trying to write expressions like:
app[.width] = "curly quew"
Also still legal at the moment, but also still broken apart...and being two separate elements means it couldn't be quoted as a unit on the left (e.g. by an assignment-oriented equal):
>> app[.width] = "curly quew"
== [app [.width] = "curly quew"]
One of the reasons we'd discussed making these kinds of constructs illegal would be to free them for new meanings.
Given that people want more density, might we think of this as a new datatype... like a PATH! or a TUPLE!, that simply has no delimiter?
Let's Imagine we call it FUSED!
(Once this was proposed as PACK!, but now packs are something different... it was named out of the way as SCRUNCH! just to avoid confusion. But now I think it's best called FUSED!)
>> p: operation(arg) ; 'operation(arg) if eval active, but likely should not be
== operation(arg)
>> type of p
== &[fused]
>> first p
== operation ; a WORD!
>> second p
== (arg) ; a GROUP! with one element
Plan -4 Issues
There's a bit of a problem in that we've been saying you could write (a)(b) and [a][b] and have it mean the same thing as (a) (b) and [a] [b]. I use this frequently, because I do not like the spacing gap you get when braces follow each other.
f: func [
some-arg [integer!]
] [
the gap there bothers me
]
f: func [
some-arg [integer!]
][
without the gap looks better
]
That would suggest the rules for fusing would disallow adjacent GROUP!s and BLOCK!s, which would rule out interesting fuseds that might represent multidimensional array access:
>> [foo[x][y]]
== [foo[x] [y]] ; would have to be a fused and a block?
Ladislav was always rather adamant that spaces should be everywhere because spaces had significance. So he wasn't in favor of the aesthetic gap-closing. If FUSED! turned out to be truly useful, then it might vindicate his belief. I dunno.
How Would It Reconcile Priority With TUPLE! and PATH! ?
The interstitial delimiters prioritize by "heft" (/ is on top of : is on top of .) And you can't get much less hefty than nothing. So fuseds would be on the bottom of the totem pole.
a.b/c.d[e f] => to path! compose/deep [a.b c.(to fused! [d [e f]])]
a.b[c d]e/f => to path! compose/deep [a.(to fused! [b [c d] e]) f]
Not that these examples are very useful, but I believe that's what they should be.
There'd Be Some Issues With Numbers
If numbers are allowed, you are going to run into trouble with things like how 1e... leads into exponential notation, and the fact that you get problematic reversals with 1a and a1. The first seems like a candidate for being a FUSED!, while the second is what we'd see as a normal WORD!
No Fusing With BLANK!-Terminated Paths or Tuples
You couldn't merge a/ and [b] to get a FUSED!, because a/[b] is a PATH!. (This is a natural consequence/feature and not a flaw.)
Also, while # is a legal "empty issue", it's also a modifier. So the #[a] probably shouldn't be a FUSED!. Unless there's some way that would fit into a broader master plan, by virtue of what that fused would mean... e.g. if # = first fused would mean something was typically a datatype... 
Anyway, a lot to think about. But if people are dug in and insistent that they have to have these notations, then we should give consideration to the idea.
So I guess the usual exemption for languages, where if the run is all words and integers, and starts with a word, it's active...otherwise 1x1 and