make QFont mergeable by adding every kind of property to the (OpenType) "features"

In QML we have font as a value type.  So it's easy to create an API like TextSelection.font in
https://codereview.qt-project.org/c/qt/qtdeclarative/+/515825 But if you select a range of text that has multiple char formats, and then you want to toggle one feature by hitting a toolbar button or a key shortcut, like let's say Italic, and you do that by passing a QFont object to QQuickTextSelection.setFont(), it's not clear that there is any way to tell that the only thing the user wanted to do was to set the italic property. A complete QFont was passed through; and in QML we can either start with a default font object (Qt.font()) or we can read the existing font for the selected text from QCursor, modify it, and send it back. Either way, it tends to make unintended changes.

In C++ one tends to call mergeCharFormat() to make one little change at a time like this. But to make declarative API that can use that function, without exposing QTextCharFormat itself, would tend require all possible properties on the TextSelection or whatever object... an explosion of properties.

I tried checking QFont::featureTags() in my setFont() function, and I see that it's an empty list in this case. So I was wishing the old features like bold and italic were there.

So maybe we just have to expose QTextCharFormat to QML as another value type, and use that instead? But QTextFormat is the parent of a whole tree of types, which don't lend themselves to being easily turned into Q_GADGETs: they would tend to have too many properties too, and that's a lot of code for moc to generate, wherever we put it.

But with this font features API (which I was initially not a fan of, because it's so open-ended), maybe we are going towards QFont being a container of an arbitrary number of properties, and maybe we will end up being able to set them all in QML?

It's like there are two patterns for OO: a fixed set of fields in each object, and/or a map for storing dynamic properties. In C++ we usuallly go for the former way by default; whereas JS chose the latter, and so did QTextFormat. (Same thing in serialization: some formats need a schema, others are self-describing.) One advantage of the map as storage is you only store what you're using, and the absence of a field is obvious; whereas with fixed properties, maybe we should be using std::optional everywhere, every Q_PROPERTY needs a RESET, and so on.