The following concerns need to be addressed for QML SFPM:

• Supporting the 'sourceModel' property in the qml in addition to the 'model' property. We currently expose both properties in SFPM, but only "model" is actually functional. Assigning to "sourceModel" does nothing. This will definitely confuse users familiar with QSortFilterProxyModel, and it's generally not great API.
• The parsing of column number against role name need to be improved. It currently assumes "display" as the default role name. However, there are models that don't provide a "display" role, such as ListModel. If the column number is explicitly given, but the role name is not, the role name should be disregarded. Only if both are explicitly given we should match against both.
• FunctionFilter and FunctionSorter taking a synthetic type as input is quite unintuitive. In particular, the type passed there is not a type of an individual model item, but rather a type for a whole row. Therefore it has to be synthetic. We could instead pass model indices and provide a method that retrieves a QVariant for a model index and role name. That's not type safe by itself, but the user can do "as" on a QVariant retrieved like this to force a specific type. In any case, this should be "advanced" functionality. The common sorting and filtering tasks should be doable with simpler primitives.
• QSortFilterProxyModel has a regular expression filter. That seems to be enough there and it would be easy to do in QML. regexp is a builtin value type after all. There could be a RegularExpressionFilter.
• Exposing JavaScript's native comparison semantics for sorting, while not a complete solution, would certainly go a long way. StringSorter already exists, but it does not in fact sort by JavaScript semantics, and it muddies the waters by providing a numericMode. Instead there should be a separate NumberSorter. StringSorter should use JavaScript's toString() semantics, NumberSorter should use valueOf(). This won't solve all problems in the world. There certainly are a lot of object without meaningful toString() and valueOf(). However, many of our builtin types have meaningful toString() and valueOf(), and most of the sorting will probably be on columns that are natively strings or numbers.
• We might add a way to override the default toString() or valueOf() with a method on the respective Sorter or Filter (e.g. "function itemToString(item: var): string", "function valueOfItem(item: var): double"). This would probably be implemented as a cascade of "as" expressions, but it would do the trick. It would be somewhat equivalent to QSortFilterProxyModel's virtual lessThan().