Here is a bit more details about Max Creation Graphs (by one of the main developers) :
I’m not saying to not have matrix access, but matrices can be absolutely brutal to work with if you have never taken a college Calculus course.
In Blender, when working with Python, working with matrices becomes a lot easier through use of the Mathutils module because you can work with simple Euler values for rotations and convert it to a matrix for use in the actual operation. For artists, you pretty much need to have a way to convert Matrices to Eulers and back again.
But from video its doesn’t look like MCG matrices are so brutal.
I took that course and it’s a pure evil 
Either way, whether the Blender devs. decide to take an ultra low-level approach like in Max or create a modifier node tree system based on the same paradigm used by Cycles. It is obvious that the only way forward with modifiers is to ditch the stack and go completely nodal.
I don’t see why my suggested ‘accessible’ method and a lower level visual programming method can’t co-exist, perhaps one can build a higher-level modifier node out of many low-level components and have those along with premade, higher-level modifier blocks.
oh no, dont ditch the stack
Have it both ways - like Max does
The stack is just a chain of nodes.
What are you talking about? Matrices are high school stuff. They’re perfectly pleasant to work with and very easy to learn. Yah, I get it that there is stuff in math that’s hard and not suitable for many artists, but matrices really aren’t one of those things.
After all the tree view in the material editor shows the entire node tree, it’s just that it’s not super clearly presented. I’d totally vote for a low-level, ICE-like node editor for modifiers/constraints.
The workflow of stacking modifiers is more convenient and takes less steps than hooking nodes. But it is not as advanced!
So for simple case modelling, I would keep the stack just the way it is (and thats why max devs kept theirs too probably).
For a more advanced setup -where I am designing a special dynamic asset that can be changed with sliders- I would use nodes.
+1 to everything Blurymind says
Keep the stack, and have the ability to add self-contained node-based modifiers, as in Max.
It’s a mistake to entirely forego a stack-based approach because you can use nodes. Nodes are powerful, and I’m a big supporter of them in many cases, but for the simplest of tasks nodes aren’t an improvement.
For simple stacks true - the stack view is sufficient.
What I would love would be the ability to link modifiers like having the same bevel modifier affect multiple objects, changing the data in one modifier also adjusting that with all other object using the same modifier data
Hmm, it’s interesting that the modifier stack vs nodes can be applied to the VSE strips too.
And +1 to cekuhnen’s suggestion about parenting a node group to multiple sources, master node…?
if one could make a modifier group and apply that as a material to objects as well oh dear what a dream …
Why not keep the stack interface, but make it use nodes under the hood. This way you can use the stack as you always have, but should you want, you can just go over to the node editor for more advanced setups. The idea being to allow you to use what you put in the stack and not have to recreate it with nodes should you decide to switch to nodes.
In addition allow in-stack usage and creation of node groups as well. Again a way of preserving the stack interface and appearance while allowing fast access to node group instances.