First, a caveat. I wouldn't advise using Tree Notation if you had an urgent need and aren't in this for at least a year, as the benefits accrue over time and will only really become impactful as the ecosystem grows. With that out of the way, let me address your questions.

> I am still trying to identify what makes your technical solution unique and better that, say, a Jupyter/Dataframe based system.

It's a low level symbolic notation. Any symbolic notation is an imperfect way to model reality. Some are better than others. I propose that Tree Notation may be the best such symbolic notation we have ever come up with. I measure "best" here as a function of capabilities and complexity. Tree Notation has all the capabilities of other symbolic notations (you can build a "data structure zoo" and you'll find that every structure has a representation in Tree Notation), without the complexities of extraneous syntax. You simply have words. You have no quotes, no parens, brackets, etc. Words laid out in geometry. Sure, about 1% of languages have done the "indent significance", such as in Python and YAML, but no one (until Tree Notation) figured out that that's all you need. You don't need any other syntax characters. Simply have rows and columns (and using indents for scope) is enough. This "simple as possible" pays dividends. For example, simple new ways to count complexity (https://jellypbc.com/posts/ezmntq-counting-complexity).

As a low level notation, you can't compare something like Jupyter/Dataframes directly to it. That would be like comparing Jupyter/Dataframes to binary notation. However, you can compare Jupyter/Dataframes to a higher level tool built on Tree Notation, such as Ohayo (http://ohayo.computer/). What does Ohayo have that Jupyter doesn't? Well it's a very high level language where you can mix data and code easily. Coding with it is very copy/paste friendly. Whole programs can be put in the URL. There's no server side backend needed—everything runs locally in your browser. Of course, there's no ecosystem or community behind Ohayo yet, but the nice thing about Tree Notation is that simplicity doesn't go out of style. If at some point the resources spring up to develop it further, I think it could be a very popular tool and community.

There's nothing semantic you can do in Tree Notation that you can't do in Jupyter/etc, as for the foreseeable future they all are running on the same hardware. But it's very pleasant to write tooling and parsers for Tree Notation since it's so simple, and as a user you get great things like seamless semantic interop with git, pleasant copy/pasting, url friendly programs, et cetera.

> Also, I am trying to understand the key conceptional differentiators. What do you mean by 2D language?

All existing 10,000+ computer languages I would call "1-D". That is, it is assumed that you have 1 read head that moves linearly along the program generally from beginning to end. Tokenizing happens, white space is stripped, an AST is built, compilations occur. 2-D languages don't have the same assumptions. You could potentially have multiple read heads. Read heads could move not just back and forth, but up and down. Of course, it will be a while before we have 2-D registers, and so for a long while we still have to compile to 1D langs, but there's a future where computing looks a lot different than today.

Another way to think of it is that currently programs are roughly transformed into a ticker tape and read linearly in order. 2D programs don't have to be, and could be read by the computer similar to how a human reads a newspaper—parsing and zooming in and out in potentially random order.

A much simpler more pragmatic definition for now could just be that a certain subset of TSV is a 2D language.