The way describes appears to be the only one. Though says the alternative is not supported, but as points out, the option shouldn’t be there then.
There’s a number of these little gotchas hidden all over UE4 where after you’ve spent a lot of time looking for what you’ve done wrong, you find out it’s just code paths exposing unintended options which won’t work and aren’t documented. (Font renderers being another example, where they don’t work with fonts imported using the new method, subsampled fbx import which can lead to surprise bad animation imports, the export to text context menu which puts out files that can’t be imported into unreal engine and have no clear use case, these are just some of the top of mind ones I’ve run into lately). I’m not sure of a fix as a user, but in general, I’d love to see Epic staff responses on forums doing more explaining how things do work, rather than magic steps or defining that which doesn’t work as unsupported. Though, I appreciate, this often means finding someone with specialized knowledge and spending more time on answers. While reading the code helps, it can only ever show us how the code, not the design or workflow intent. Intent is critical to deciding how we structure our projects.
For example, is there a superior use case to the blueprint class construction example? i.e. is the one there in the context menu ever what’s desired? Is there anything it provides which the blueprint widget does not? It seems like it’s just a subset, so has no use beyond a full one. I’d love to hear more on the difference, because it feels close, but not quite the same, as the difference between a C++ class vs an instantiation of it.