This looks nice, but perhaps you want this to be something inherent to the bending springs?

I don't know if the work you did previously with the bending springs are in master yet, but with those you could have them also push out vertices if there is compression going on.

IE, if there is compression and the bending spring already has the vert where it should be, it can move the vert out in the normal direction.

No, it is still using only length constraints. I'm waiting to have all brushes before changing the constraints model because I still don't know if I'm going to need to add more features to the solver to support them.
Is it ok to leave the noise with a small value or this should be a configurable parameter?

I've talked to Sergey about this and we think that having proper bending springs and using them to prevent this is the proper way to go.

Then we only nudge vertices when we need to instead of always introducing noise into the simulation.

Ok, then I'll try to use angular constraints in the solver for 2.91, but first I would like to move the constraints storage to the nodes so the simulation can be enabled/disabled by area.

@Sebastian Parborg (zeddb) As the bending constraints won't be in time for the 2.91 release, can we merge this a a temporal workaround for this issue?
I can probably try to make a more configurable simulation noise feature to generate more random folds on even topology using this patch as a base.

There is still 1 week in bcon2 for new features, and then about 3-4 weeks in bcon3 for bugfix.
Is implementation of bending springs really a 3 months project? What's the status of it?

I thought we had the bending springs working when I helped you implement them a while back?

However, I don't really like accepting workarounds like this with the promise that it will be fixed properly later.

Mainly because the current (non sculpt) physics code is filled to the brim with things like this.
I don't want the sculpt physics code to potentially get into the same state.