Well, from the way you described it above I’ve changed my mind on it and can see its use, particularly because it doesn’t disturb existing methods. People can choose to use it or ignore it.
I’ve a feeling that when the internet is awash in Zbrush levels of free custom brushes the complaints might die down… 
Also modular nature of nodes and the code behind them opens up a possibility of making new brush functionalities that were impossible, or impractical to implement with current brush engine design.
Add-on developers might be happy about it.
That escalated rather quickly 
Nice, a little breath of fresh air. Probably the folks from Maxon or Autodesk running out of options.
This is comedy gold 
Right? Votes to keep him/her/them around?
A new local mascot?
Node-based brushes should also lead to better ways to expose node values to change in a properties window across Blender versus editing the node tree values themselves too. I don’t think anyone wants to go tree diving just to tweak a value.
Understandable… Blender is famous for its over-complicated workflows… so the concern is expected…
Bsides, many essentiall features are still missing in sculpt mode, so why not focus on that first, instead of wasting time building a new entire node system no one asked for…
This should be something for the future, once the basics are pretty solid…
Don’t say that out loud, you might jinx us and they might come back 
Sometimes I wonder if Blender devs think people who do digital sculpting professionally lie every time they say they use 4 brushes 95% of the time (may 10 99% of the time). It’s like they think “common, they MUST be using some secret sauce crazy math script brush to so things on Zbrush”.
That’ll be done, shortly after the brush node thingy is up and running in God knows when.
If a brush node chain (which is a GUI for a script) is completely re-evaluated with each brush stroke, Sculpt Mode speed will suffer at higher polygon counts and on slower machines. Therefore I hope the node system for a Sculpt Mode brush will be evaluated only once to trigger all desired settings, while brushing happens at maximum efficiency.
Yeah, I’m just bad with words, I think we’re saying the same thing. What I mean is that the node system (or whatever they come up with) won’t deal with low-level things like “move vertex here” the way geometry nodes does. There are core behaviors for each brush that will be unchangeable: Clay Strips behaves differently than Trim or Pinch. But they all have common options like auto-smooth, or a stroke method, or falloff curve. Those settings will be separated into nodes, and the nodes will give much more flexibility than a cluttered, per-defined menu with sliders and checkboxes.
Nobody is currently working on nodes for brushes. For the moment, it is just an idea from Pablo’s original proposal posted, years ago.
There is no task about it on d.b.o.
It was just mentioned on dev meeting, about brush management, as a medium priority undefined todo.
In Pablo’s proposal, the nodes should be used to allow user to change formula of deformation.
Then, in this thread, I suggested to use them to customize display of brush settings, in properties editor.
Brush would work with a default value for an hidden advanced property.
If the user wants to reveal slider or boolean check relative to property, he just has to add corresponding node to brush nodetree.
If the user wants to hide properties of brush that he never uses, he removes them from the nodetree.
The same way that you can work with principled shader node (displaying 28 settings) or a nodegroup of same shader (exposing only 10 settings).
In Blender 3.3, a clay strips brush UI displays a dozen of global settings, a dozen inside Stroke sub-panel, other dozen under Advanced sub-panel and the 3 remaining sub-panels can count for another dozen.
Same brush, in sculpt-dev branch has a dozen more of global settings, 5 more setings in Advanced sub-panel. And future improvements should add more settings to Texture and Stroke sub-panels.
So, I confirm that future sculpt brushes should have around 50 or 60 settings to customize them.
A system to limit their display to essential ones will be welcomed.
But for the moment, developers did not even choose, if they will try to create nodes for brushes for one of this purpose.
In same meeting, Auto-masking features were mentioned as high priority. For that, there are patches waiting. They have been reviewed by Julien who asked some changes.
Joe worked on fixing bugs, before 3.3 release.
Now, we should see progress in master, in upcoming weeks.
Yes, that would be ridiculous. I was thinking that it would be a compiled/saved tool, certainly not a live tool.
I thought the open movies were supposed to be made with standard blender as much as possible?
To reduce the complexity/amount of brush options that are exposed. That’s what I’m hoping for.
I would love to see a list of features put in a poll and see which ones are voted to the top. I suspect a three-way tie between brush management, sculpt layers, and multi-res bugs.
Those features might not be in the skill set of the current sole dev.
The features he is working on are all probably part of the journey to make a proper mental map in his head of how all the code comes together. In the long run these things will benefit future developers working on other things. Just the ability to explore how 73 brush settings work together by tweaking some nodes instead of writing C and waiting for the whole thing to compile before you can test an idea, that’s a huge boon.
Consider this task: We need people switching from zbrush to have 100% exactly replicated zbrush behaviour in the most used brushes. We also need people who have been sculpting in Blender for a decade to have exactly the same experience they have been used to.
The only way to achieve this is to #1 fully explore, understand, and document exactly what the current Blender brushes are doing under the hood, #2 fully understand all settings and expose all settings so people familiar with zbrush and blender can do the hard work of fine tuning and documenting those settings. #3 provide a set of brush presets for traditional blender users and another set for zbrush users. - I see a node system as a very fast and easy way of helping that process along, assuming something like that process is happening.
Does anyone have any idea how long ago the brush system was made, by how many different people, and how many of those people are still involved?
Not always the case. Imagine a built in brush node that represents the source code of the clay strips brush. Lets say I want my clay strips to be rounded at low pen pressure and very square at high pen pressure. I can take pen pressure input value, run it through a float curve node and into the auto-smooth and tip roundness inputs of the clay strips node. I don’t see any reason why that float curve node would slow down anything.
I think they will make thoughtful decisions, Julien is doing a fantastic job, very underappreciated in my opinion.
Don’t underestimate the skills of the blender devs, they are very talented, and Joseph clearly got powerful skills… the issues are the priorities and choices, IMHO…
No, that’s a weird way of seeing it…
Things shouldn’t be done with the goal of pleasing users of a certain software… we are sculptors, and we just want the best tools possible for the job, that’s all…
Forget this idea of providing a “set of brush presets for traditional blender users and another set for zbrush users” this makes no sense…
If the sculpting toolset reaches a level that is really really good and polished, then it will be good enough for every digital sculptor out there, it doesn’t matter if you’re coming from zbrush/mudbox/3dcoat etc…
What is good is good…
The devs. are talented and know multiple areas of the code, yes, but it is naive to think they have this almost supernatural ability to instantly make commits for any area of Blender they wish to work on. They are humans, and I would like to hear it if you know someone who is the coder equivalent to Superman. Do you seriously think Julian for instance (who was initially hired to work as a UI dev) can up and decide he is going to write new and improved algorithms for Mantaflow today?
If I had to name someone, that would be Maxime Rouca, the genius developer of ZRemesher / Quad Remesher, UV Master and Decimation Master for ZBrush. Particularly ZRemesher / Quad Remesher is of such a brilliant level that nobody has managed to equal or surpass it in the almost 10 years since it was introduced.