A lot of improvements are possible, based on 20 years of progress in interactive systems, and just overall computing performance.

The documentation includes a big table of attributes that graphviz tools recognize.

With the availability of LLMs, there is better automated support now to find features that are needed. Just imagining here, but "make the layout fill the available space" or "make all the nodes look like points with associated text labels" (not sure if that even works but it should).

Isn't the EPL "weak copyleft", so LGPL-ish? Would companies raise similar issues about glibc and GNU libstdc++? Just curious.

Also, by focusing on control flow graphs, the proposed method does a better job with domain-specific layout. Apparently CFG visualization and exploration is a current topic; e.g. CFGExplorer. Probably Graphviz some users would benefit if it incorporated CFG-friendly level assignment as an option.

There's already machinery in Graphviz to support polylines instead of splines, and to control edge ordering, but it is not well tested or documented. It seems tempting to incorporate an edge routing algorithm of Brandes and Kopf, based on long vertical runs with at most 2 bends per edge. This seems close to a master's degree worth of work to understand and implement.

Graphviz started almost 40 years ago, is only supported by a few (one or two?) 2nd-generation volunteers with no 3rd generation on the scene yet. Over the years we've had plenty of our own disdainful "What is all this junk" moments, about our own code and other people's (c.f. various xkcd comics), but sometimes a better perspective is asking "What is being optimized that led to some team choosing or ending up at this point in the design space". Generally, the market is addicted to features.

It is a little dismaying to see the relatively slow progress in the broad field of declarative 2d diagramming. Given the way the pendulum has swung so hard back toward language based methods and away from using interaction to do everything, you'd think there would be a bigger payoff now for doing the work. Unfortuantely tool-making has always been a tough market. The customers are generally smart, demanding, and work in cost centers so don't have generous budgets.

What is the most important problem anyone has solved this way?

Speaking as somewhat of a co-defendant.

There was a published study, Wrangling Messy CSV Files by Detecting Row and Type Patterns by Gerrit J. J. van den Burg, Alfredo Nazábal, and Charles Sutton (Data Mining and Knowledge Discovery, 2019) that showed many pitfalls with parsing CSV files found on GitHub. They achieved 97%. It's easy to write code that slings out some text fields separated by commas, with the objective of using a human-readable portable format.

You can learn even more by allowing autofuzz to test your nice simple code to parse human readable files.

Sketching backed by automated cleanup can be good for entering small diagrams. There used to be an iOS app based on graphviz: http://instaviz.com

Constraint-based interactive layout may be underinvested, as a consequence of too many disappointments and false starts in the 1980s.

LLMs seem ill-suited to solving the optimization of combinatorial and geometric constraints and objectives required for good diagram layout. Overall, one has to admire the directness and simplicity of mermaid. Also, it would be great to someday see a practical tool with the quality and generality of the ultra-compact grid layout prototype from the Monash group, https://ialab.it.monash.edu/~dwyer/papers/gridlayout2015.pdf (2015!!)

There's this, too, https://academic.oup.com/mbe/article/33/8/2163/2579233 and it's implemented at http://phylo.io

For many of us, curing cancer may someday become more important than almost anything else a computer can help us to do. It's just there are so many building blocks to solving truly complex problems; we must respect all that.

Someone could implement this as a feature in graphviz. It might take a day to implement.

There are probably other "solutions" that already handle this more gracefully, but otherwise don't have a very complete set of features relative to graphviz.

It's reasonable (and constructive) for you to complain, but your "issue" is representative of a wide set of "issues" we've seen, and the real problem is we're just a little unimportant niche service and all this work is being done by volunteers and they mainly work on the things they know how to do.

It would be good to find ways to make the internal algorithms and their parameters more "open" or more easily parameterized and recombined in novel ways. It would be good to find ways to rely on more generic optimization methods, though software like this is probably skating on the edge of computational intractability (not to mention usability or interpretability issues) so it's a very challenging problem.

Kudos.

Successful systems like Tom Sawyer Software or yWorks have dynamic or incremental layout features. The market of course strongly rewarded work on interactive systems like Visio that were well integrated into larger platforms.

Not sure who remembers but high performance incremental constraint-based layout was one of the computer science lights that failed in the 1980s and 90s but with so many fundamental advances in technology (processors, algorithms, solvers, software platforms) and new emphasis on language-based approaches (in part due to LLMs) there might be a better opportunity now.

Anyway it's a hard problem, it's not as if nobody was aware of it.