Paragraphs Form - Options - Should be extendable

How much is this related to these issues:
#2868155: Add paragraph bundle to widget forms to allow easier editing of paragraph forms
#2905320: Paragraphs Form - "Add Mode" - should be extendable

I'm only maintaining new features like this inside the new experimental widget.
The other Classic should change as few as possible and will likely be deprecated at some point.

I agree about what you describe, but we first should outline the new APIs we need to cover these use cases before implementing.
Or you jump into implementing the hooks with a prototype... without any guarantee yet if we are happy with what we learn.

The test module should implement the hooks to provide a common example use cases of a new add mode.

My proposal was also, if we manage to make the add mode extensible, it would be interesting to consider outsourcing the different current add modes into separate files.. The widget code might be much more compact.

Please move the poposal into the issue summary. Chances are you want to promote this issue to a META issue. This means code / patches only in child issues.

There are no other active Maintainers of the 8.x branch.

We have spent a lot of time to refactor the widget and remove complexity. Yet some complexity grew again by new functionality.

Our time is very limited as long as direct funding of our Paragraph work is on the current minimal level.
I appreciate any type of contribution. There are two problems though:
* First, we spent more than 2 weeks of work in 2017 to talk to potential contributors that then didn't contribute.
* Proposals like this are adding complexity we then need to maintain. Thus it adds work in the short term to review, communicate and in the long term.

There would be a simple solution: If you want to provide incentive for us to work on your priorities, you could help us to resolve major / critical issues in Paragraphs.

I re-read the proposal above and it's still hard to answer.
The mail you wrote proposed two approaches. I'm not sure about both.

In many cases, we need to prototype proposals to understand if they are the right direction.

First, there is already an extension point for per-paragraph operations. We use this heavily, but it's limited to the "..." button. We want to be very careful with adding too many extension points as hooks can add messi spaghetti-like code sequences... We intentionally started to drop settings that don't provide value anymore to straighten the code.

It looks like we will add Paragraph hooks so every relevant aspect of the widget is easy to alter:
#2868155: Add paragraph bundle to widget forms to allow easier editing of paragraph forms
The hooks are not yet completely defined, but it looks like a plugin system dedicated to the add mode only seems obsolete.
These hooks are needed anyway, so please help us providing example use cases and implement test coverage there.

We spent iterating on the experimental widget for about a year now. Thunder is starting to adapt it as well and we wanted to stabilise it.
We tried multiple approaches to further separate it, but it led to growing complexity and indirection. We picked specific improvements of these iterations, but dropped the idea of splitting the widget further.

I'm still open to further architectural changes if they are a major architectural improvement. The conditions for an acceptable situation would be:
* The code complexity doesn't grow with artificial constructions
* Current code that covers multiple cases are split into separate plugins
* I can still follow the widget lifecycle and an edit + add + save process easily.

But i doubt that this is possible. In fact, working on drag & drop and other improvements during the past months showed us that the key complexity originates in architectural design and limitations of the (Drupal 8 core) widget lifecycle combined with the form lifecycle. Their architecture requires workarounds that are hard to abstract away, leading to repeated complexity for every code interfering with a Paragraph widget lifecycle. Every Plugin or sub-plugin would be hit by it.

So while i'm interested in prototyping the separation: If all Paragraph modes are plugins, what's the purpose of the Paragraph widget itself? It seems to me then every of these specific widgets could simply be regular standalone widgets. We could still move some parts into Traits or so to avoid too much code duplication, or a Widget base.

That said, if these learnings are not mind blowing, chances are that we would need to offer such a solution as a third newer modular widget and stabilize the current experimental one like it is now.

Great @sgurlt, we're looking forward to updates. :-)