Ok, so to conclude...
There are functional bits, such as:
* The read-only pre-eval. They could be done by various other constructs (e.g. extended "with" / in itself a topic for fierce discussions) => but thats not the point.
* The check of all columns (all conditions in each line) being present (albeit, present does not imply correct)
There are bits that already exists.
* Counting how many "when" lines there are. => Same as counting IF lines.
There is a danger (the extend of which we have a major disagreement on) of messing things up, since it relies on good vertical alignment (and the users ability to track this alignment).
Of course an editor can draw vertical help lines, but then the benefit comes from the editor and not the feature
We simple have different opinions on the "readability" bit.
I do agree that tables can present data in a very readable manner, but that is if the app that displays the data supports displaying the table, with guidelines or the like.
In a text editor "tab" like formatting (even with spaces) can improve readability. But IMHO it depends on the data already being somewhat readable before. "Tab" are not magically turning unreadable data to readable. Hence my demand for "as"
There are potential additions, such as adding "as" to evaluate. ("If" already has them). Apparently we can not agree on this. But it probably depends on how well your Editor helps tracking columns, and even more on what the actual use case of "evaluate" is.
- Assuming best case: Fits on one screen, and each column has different types.
- Assuming worst case: goes way off screen, and columns have compatible types.
Of course even the best feature has a "bad" worst case.
However I cannot help but wonder: One of the "advantages" you listed (the ability to count "when" and compare to the expect variation count of a boolean matrix) is actually falling into "worst case": all/most columns are boolean, and a long list of "also true also false also false also true ....", is really easy to mix up (swap columns). Maybe that is not the typical use case, but it is the example that you build part of your case on.
Anyway, apparently at least you had never issues with accidental mix ups...
As for your graph: The have diff levels of details. Also despite we type "else if" and not "elseif" for the human reader (and for this usecase) they are the same. If you read it as "elseif" then there is no nesting.
"nested if" are different to "waterfall if elseif...". And like "nested if", you can have "nested evaluate" (though that would be foolish)
One last note on readable and screen size.
"evaluate" fits into one particular "need". Since it has a shorter syntax, and omits "as alias" the overall representation fits on a smaller space. (And yes as long as this space is
very small, it is still readable...).
So if one has a lot of data, and needs to "squeeze" it onto one screen, then "evaluate" can help.
Though the word "squeeze" already tells, that this is not a good thing. It simple opens a way to defer solving one problem by choosing a new "lesser" problem.
For the very same reason, I have seen people (and done myself) using none-descriptive short identifiers and weird code formatting.
The real answer (one of the answers) is to modularize your code (refactor, split out some logic, ....).