Whoa. I'm afraid to look ;-) My immediate thought is, "lets combine all the mental fun of stack juggling from forth with the tree juggling from lisp." My brain hurts!
Combining aspects of Lisp with aspects of Forth is not a new idea. The RPN calculators offered by HP used a language called RPL ("Reverse Polish Lisp")[1], including a user-level version (a little more Lisp-y) and a system-level version (a little more Forth-y). While RPL is what came immediately to my mind, I doubt it's the only historical example of such a combination; people have been drawing similarities between the Lisp family and the Forth family for ages.
While I do get that feel with PostScript, as far as I can tell it was accidental rather than a conscious design decision.
The stack-oriented nature of PostScript appears to have been influenced by the engineers' experiences with working with some stack-oriented architectures from Burroughs [1], rather than from Forth. Some aspects of PostScript were influenced heavily by other languages in use at Xerox PARC during the Interpress era [ibid], most notably Cedar, but considering that Interlisp was also in use at the time, it's not unreasonable to conjecture that it had some influence; however, any such Lisp influence was likely subconscious, and none of the people working on Interpress or PostScript or their forebears seems to explicated such an influence (as far as I can find).
Charles Geschke and John Warnock, the co-founders of Adobe, both deny any influence from Forth, suspecting that some overlap of design requirements between the two languages led to the shared properties [2]. I know that can be hard to believe, given the striking similarity of the two languages, but it's not the only time that concatenative programming would have been independently invented: Manfred von Thun's Joy language is likewise similar to Forth, but, again, not inspired by it. Whereas the similarity of PostScript to Forth can be explained by a simultaneous need for portability and dynamism in tightly-constrained environments, Joy's similarity to Forth is a result of a desire for algebraic manipulation of program text (Forth's (somewhat) having this property may have been a conscious design decision, but I'd bet cold, hard cash that it was a happy accident).
Indeed, any of these stack-oriented concatenative languages are computationally equivalent to a transformation monoid (algebra of functions and function composition) where evaluation proceeds according to a (possibly effectful) term-rewriting relation. Viewed in this light, the stack effectively becomes a mere implementation detail as far as the semantics are concerned, but I think that any language designer starting with such a monoid+rewriting semantics, when facing reasonable implementation on real hardware, is likely to come up with something quite similar to Forth &c. That is to say, starting with a low-level focus on efficient and portable implementation, or starting with a high-level focus on code representation as algebraic terms, there's a good chance you'll wind up with something similar to an established concatenative language, whether you mean to or not.
Besides basic semantics, there's not that much stack juggling going on really. Cixl offers four stack operators, drop, dup, swap and clear; the idea is to use more convenient constructs like let bindings, closures and multi methods to keep the stack tidy.