This is a wonderful idea, but by the given numbering scheme, I can identify a slew of problems.
[1a. If] Note
This is the first time we see synchronous calls, decisioning, and the representation makes no specific callout to the structure. The structure IS the case.
[4. Break] InconsistencyConfusion
This is the first time we see a specific part of the flow called out as the structure (it isn't a structure). This is flow control, not a construct. This confusion plagues the rest of the document.
[7. Switch (No Fall-Through)] InconsistencyConfusion
This is the same as If/elseif.../else/, but the post goes with the oddly specific "switch". Would be more appropriate as [1c. if/elseif.../else] and a [1d. Switch] - The different terminology if/switch does not change the fact they are the same structure. Grouping Switch-type by name is a bad choice.
[9. Local Goto] Omission
The Goto example has no exit node.
[11. Exceptions] Mistake
The exception travels the stack, meaning (from the perspective of the original parent function), from grandchild to the child, to the parent catch.
[12. Finally] OmissionConfusion
Finally should be it's own block, since it is treated as such and has an implicit catch mechanism, even if it's not always required in the syntax.
[13. Blocking, Synchronous Calls] Confusion
This is rather pointless. All the flows, prior, were blocking. Now introducing another metaphor that changes past examples is inconsistent. Blocks which are synchronous (blocking) are represented by 2 different forms. It's unnecessary.
[14a. Non-Blocking, Asynchronous Call, Callback] InconsistencyConfusion
There is a whole function called, which should be represented by a starting and ending node.
[14b. Device Input] InconsistencyConfusion
This isn't even a different construct. Event handling is what this is and is poorly represented, in the same way as 14a.
[15. Framework] MistakeConfusion
This isn't a construct, nor is it an accurate representation. Frameworks are a collection of idioms, which usually has little to do with constructs (as defined in the beginning). It feels like the author has gone off the rails here.
[18 Come-from & 19 Aspects & 21 Destructor] Confusion?
The size of the block is supposed to indicate a specific syntax, which is inappropriate for describing logical constructs. They should be full sized and optionally labeled blocks, as they are evaluated.
[20 Dependency Injection] Confusion
This is another "timing adds a new way to represent things" issue. There's no difference between an Aspect and DI, logically.
[22. Defer] *Confusion
Adding data (even a function) to a separate stack, which is called later, does not make the diagram presented.
All in all, this needs work.
Even the grouping description at the bottom does nothing to help make this more useful.
[1a. If] Note This is the first time we see synchronous calls, decisioning, and the representation makes no specific callout to the structure. The structure IS the case.
[4. Break] InconsistencyConfusion This is the first time we see a specific part of the flow called out as the structure (it isn't a structure). This is flow control, not a construct. This confusion plagues the rest of the document.
[7. Switch (No Fall-Through)] InconsistencyConfusion This is the same as If/elseif.../else/, but the post goes with the oddly specific "switch". Would be more appropriate as [1c. if/elseif.../else] and a [1d. Switch] - The different terminology if/switch does not change the fact they are the same structure. Grouping Switch-type by name is a bad choice.
[9. Local Goto] Omission The Goto example has no exit node.
[11. Exceptions] Mistake The exception travels the stack, meaning (from the perspective of the original parent function), from grandchild to the child, to the parent catch.
[12. Finally] OmissionConfusion Finally should be it's own block, since it is treated as such and has an implicit catch mechanism, even if it's not always required in the syntax.
[13. Blocking, Synchronous Calls] Confusion This is rather pointless. All the flows, prior, were blocking. Now introducing another metaphor that changes past examples is inconsistent. Blocks which are synchronous (blocking) are represented by 2 different forms. It's unnecessary.
[14a. Non-Blocking, Asynchronous Call, Callback] InconsistencyConfusion There is a whole function called, which should be represented by a starting and ending node.
[14b. Device Input] InconsistencyConfusion This isn't even a different construct. Event handling is what this is and is poorly represented, in the same way as 14a.
[15. Framework] MistakeConfusion This isn't a construct, nor is it an accurate representation. Frameworks are a collection of idioms, which usually has little to do with constructs (as defined in the beginning). It feels like the author has gone off the rails here.
[18 Come-from & 19 Aspects & 21 Destructor] Confusion? The size of the block is supposed to indicate a specific syntax, which is inappropriate for describing logical constructs. They should be full sized and optionally labeled blocks, as they are evaluated.
[20 Dependency Injection] Confusion This is another "timing adds a new way to represent things" issue. There's no difference between an Aspect and DI, logically.
[22. Defer] *Confusion Adding data (even a function) to a separate stack, which is called later, does not make the diagram presented.
All in all, this needs work. Even the grouping description at the bottom does nothing to help make this more useful.