The question: Every element's options modal took ~873 ms and ~6.7 MB to open. An existing "lazy multi-picker" optimisation was already in place and clearly not working. What is actually costing that, and can it be deferred without risking saved values?

The question: Some people want the block editor but still want the Unyson+ options framework. Getting elements in front of them could mean porting them to native blocks — block.json, React edit, attributes per option — or exposing the elements that already exist through a bridge. Which, and what does the bridge actually have to do?

The question: fw.js called Backbone.Model.extend and Backbone.View.extend in exactly two places. Replacing them looked like an afternoon. Then the modal underneath turned out to be wp.media.view.MediaFrame — WordPress's media frame, which is Backbone, and which Backbone still loads for anyway. Is removing it worth the risk?

The question: The most common criticism aimed at anything descended from Unyson is that the extension layout itself is obsolete — a config.php / options.php / views/ / static/ folder, options declared as PHP arrays, output rendered through a shortcode. Modern WordPress, the argument goes, means block.json, React InspectorControls, PSR-4 autoloading and a webpack build. Is the UnysonPlus extension architecture legacy debt that has to be rewritten?

The question. A Tailwind-built source (a jiro.build finance template) converted badly on localhost. The obvious shortcut surfaced: the source markup is full of Tailwind utilities that already encode the design (grid grid-cols-2 gap-16 items-center, min-h-screen, absolute inset-0, text-4xl font-bold) — so why does the converter bother mapping each element to native shortcode options at all? Why not paste the source element's class string straight into the shortcode's Advanced → Custom CSS Class (css_class) field and let those classes do the work?

The question: qTip2 has been unmaintained since 2016, and we replaced it with Floating UI. The old implementation put its vendor everywhere — .qtip-fw class names, a 'qtip' script handle, $.fn.qtip(). Do we carry that naming over to the new library and call things floating-ui, or name them something else?

The question: The framework's biggest reputational liability is the inherited "Unyson is outdated" perception. A technology audit of the plugin showed that's largely stale for this fork. Should we publish a public Technology page to rebut it — and if so, how do we handle the fact that such a page also has to acknowledge the remaining legacy?

The question: Shape dividers are used by exactly one place — the Section. So why give them their own Components tab instead of folding them into Section Styles? Should a divider preset carry its own colour? And since the Top and Bottom pickers show the same shapes, should Bottom just be a flip of Top, or should we ship separate bottom presets?

The question: A button set stores the same value a radio stores — one key from a fixed set of choices. Everything else is presentation. So should it be a new option type at all, or just 'display' => 'buttons' on radio?

The question. We just moved the Section shortcode's per-instance styling out of inline style= and into stylesheets: Min Height (a fixed enum) became predefined .section--minh-{40|60|80|100} classes, Container Width (a user-extensible named-width library) and the vertical-align flex became .u{hash}-scoped rules in the per-page page-{id}.css. The background (color / gradient / image / overlay) is now the only thing the section still prints as an inline style="background-…". Should it move to page-{id}.css as well — for a fully inline-free markup — or stay inline?