I wonder how hard it is to fix that it doesn't nest? Clearly, the algorithm pulls out a multi-line piece of code out of a boxed cell. The #2dcond is a piece of multi-line syntax. Maybe it's one-liner fix in the code. Unless something like the box recognition logic is confused by nested box material.
Sorry for the long delay, but I needed some time to think about it and to draw it.
The problem are free floating cells. (I don't know if they have a technical name.)
For example
#lang 2d racket
(require 2d/cond)
(define (myfun a b c d e f)
#2dcond
╔═══╦═══╦═══════╦═══╗
║ ║ a ║ b ║ c ║
╠═══╬═══╩═══════╩═══╣
║ d ║ 0 ║
╠═══╣ ╔═══════╗ ║
║ e ║ ║ 1 ║ ║
╠═══╣ ╚═══════╝ ║
║ f ║ ║
╚═══╩═══════════════╝)
(myfun #true #f #f #true #f #f) ;==> 0
(myfun #f #true #f #f #true #f) ;==> 1
In a variant with " " to make a sring, you get
#lang 2d racket
(require 2d/cond)
(define (myfun a b c d e f)
#2dcond
╔═══╦═══╦═══════╦═══╗
║ ║ a ║ b ║ c ║
╠═══╬═══╩═══════╩═══╣
║ d ║ " ║
╠═══╣ ╔═══════╗ ║
║ e ║ ║ 1 ║ ║
╠═══╣ ╚═══════╝ ║
║ f ║ " ║
╚═══╩═══════════════╝)
(myfun #true #f #f #true #f #f) ;==> " \n \n \n \n
(myfun #f #true #f #f #true #f) ;==> 1
Should the table parse first the folating cell in the middel or should the " " include the cell as part of the string.
Now
#lang 2d racket
(require 2d/cond)
; res, it's an error
(define (myfun a b c d e f)
#2dcond
╔═══╦═══╦═══════╦═══╗
║ ║ a ║ b ║ c ║
╠═══╬═══╩═══════╩═══╣
║ d ║ #2dcond ║
╠═══╣ ╔═══════╗ ║
║ e ║ ║ 1 ║ ║
╠═══╣ ╚═══════╝ ║
║ f ║ ║
╚═══╩═══════════════╝)
(myfun #true #f #f #true #f #f) ;==> ???
(myfun #f #true #f #f #true #f) ;==> ???
This is an error, but imagine that the middel cell has the correct shape. I like the idea of nesting #2dcond but it looks difficult to make a consistet rule when there are floating cells. :(
