Yes, exactly.
Oh, there may be a ton of improvements:
I am glad that in ClassicPress common sense wins.
I especially like these 2 suggestions. There’s always a handful of widgets in my way that I’d likely never use.
Neither of these makes sense on the Widget screen.
Additional or standard widget areas would still have to be output somehow on the front end (and core should stay out of that).
Core should add ability to this.
And I didn’t understand your point about “have to be output somehow on the front end”. Idea is exactly about creating abilities to create output areas not only in sidebars, header and footer, but anywhere else. Managing plugin output via widgets is much easier than via additional code.
Have you written a theme? The theme decides where the widget areas go, although plugins can hook in and output more. Core should not be involved in that because there’s no good way to do that generically and still work with the theme’s design/layout/CSS. If you think so, you need to go back to WordPress because that’s where they are heading.
This is the limited approach.
Like I posted before, if you want to add “share on social networks” and “author box” or “subscribe box” plugins output after post, now the customizing of the output order is a nightmare. With “widgets after post” area this can be done on the fly. No, this is nothing to do with theme, contrary, this should be completely theme independent.
This is exactly what themes do or should do ~ you can add a widget area literally anywhere you like.
Before the post? You got it,
After the post? Yes, there too.
After the first paragraph? Why not!..and so on.
The only one I haven’t figured our yet is after so many words in a paragraph but with a bit of time that too is possible.
Core has no way of knowing a given theme’s structure and therefore should not be handling anything that is classed as “Frontend Design” output.
If you are a coder. But if not?
That is why “Developers” exists ~ use one of the themes that does it or a plugin that hooks into those areas to facilitate the option. If it does not exist then we’ll create it 
All widgets falls to the “Frontend Design” definition.
Hence the argument that it should be the theme that handles the location of their output and not Core.
Core handles the Backend, plugins extend core and themes handle the frontend output of both Core and plugins. Plugins can take on some frontend handling too if the developer so desires.
It will be the end of the ClassicPress. Joomla is on this stage.
I think you meant WordPress?
It is for this very reason WordPress is where it is today ~ A wanna Do IT All CMS! ClassicPress is aiming to avoid those mistake
No. Core, additional (not core) functionality, and design are 3 different beasts and should be handled differently. Widgets are functionality, not design. The same design (I mean, the same theme) can be applied to the two very different sites with very different functionality. The only difference - in the plugins and (about this is my idea) widgets. Now, with different plugins you can have different site, with extended widget functionality can be easier to manage output of those plugins.
I think we’ve gone off on a tangent here.
Maybe a new thread is in order? With questions such as…
1: What widgets should be baked into Core ~ the current defaults?
2: Add more to the default list?..or
3: Let extensions define the available new widgets and also extend the defaults?
4: Should Core provide widgets at all?
Maybe less or no at al; it can be defined in the settings of “Widgets” core plugin, or similar.
Yes, we have this functionality now, and it is very useful. We should encourage plugins output thru widgets, not directly to the frontend. The mess in the area after post is the best case, how not to be done.
In the current widget screen, if you drag a widget into a sidebar, that widget becomes live on site.
This isn’t always what you want, you should be able preview / save draft before putting changes to sidebar live.
In the Customizer a widget placed in a sidebar does not show on the front until the publish button is clicked and a save is triggered. The Widgets Screen could do with a similar functionality.
It is even worse, any change you do has an immediate impact on the front end. there probably needs to be some “design” toggle that will make the screen behave like the customizer by saving the settings into temporary storage until they are applied.
But then… we already have the customizer in which this can be done. I know that the customizer is a popular feature to hate, but maybe the question should be how to integrate the current widgets screen to operate in the context of the customizer.
You can’t integrate a bus into an airplane, they are different beasts.
In the customizer, the customisation options are presented in an insanely small area; this leads to the terrible UI.
What (maybe) can be integrated, is widgets and menu. With menu management something should be done too. I guess that maybe menu management can be a part of the widget management. This is a big redesign, and maybe it is a task to the ClassicPress v3. I expect many discussions here.
Valid point, the [Save] button can be a useful addition. Or “design mode”, when changes are visible only for you, similar to the troubleshooting mode.
Now i am writing 3 petitions regarding widgets, when they will be well thought, i will publish them.
This is why I do all my non page builder (not a fan of them) based designs in the Customizer ~ still the best option even with it’s limitations.