Unfortunately for us JUCE seems to be about implementing ROLI-needed features first followed by letting features trickle down to licensees. I think this is more than fair given the scope of JUCE, the small number of developers working on it, and the relatively inexpensive licensing terms.
I would think something like rich WYSIWYG would be far out of the scope of JUCE (like another “heavy” content authoring component often requested, a piano roll). JUCE provides all the necessary heavily-tested cross platform building blocks necessary to implement this yourself.
Example: I needed a bunch of low-level networking stuff (raw socket read/write, raw packet inspection). This is clearly outside the scope of JUCE, which provides a simple socket abstraction. So I wrote my own in the JUCE style using libpcap using all JUCE code and it fit together easily! Or I needed a much more customizable slider class based on inheritance rather than an enum so I wrote one. The way I’ve always seen it JUCE isn’t about really heavy duty features (unless they’re important to ROLI, like BLOCKS support), it’s about giving you robust, portable building blocks to assemble things.
In a post-ROLI acquisition world, I think it’s safest to assume that whatever you have when you buy a license is what you’re gonna get + some bug fixes - just look at how JUCE 4 users were screwed out of the DSP module, which was a headliner feature to push users to buy JUCE 4 licenses.
If I were you I wouldn’t hold my breath on any of these except maybe video functions (Jules has said in the past he wants to expand the video functionality a bit).