These are a number of good suggestions that might make a good start for the Q1 Ideas Forum!
Note: This external post illustrates the same frustration of OQL being to unknown in the Mendix community, the power of it, and its need of some additional features.
I thought I'd chime in with an answer to the question that isn't an answer to the question, like the answers above this one. :-)
I think René asked a very interesting question here and I would love to hear an official answer from Mendix. I share René's opinion that the power of OQL is greatly overlooked. It should play a much more important role in the development of the toolset, as far as I'm concerned.
IMHO OQL can be expanded with some neat features to give Mendix more business reporting power.
On my wish list are string functions as basic as concatenate and substring
There are no plans to deprecate OQL, very interested to hear your needs around OQL. What improvements do you need, when you prefer OQL over XPATH or XPATH over OQL?
Our first focus is to improve Xpath retrieve performance, which would reduce the need for OQL for this purpose. What changes did you make in the OQL compared to your Xpath to achieve your performance improvements. Would be interested to know if this is a generic improvement we can make for Xpaths.
It looks like the new databaseconnector Mx 6.7 might make OQL redundant. We tested it in a POC on the application database itself and it works fine (great performance). Use of db functions in selections is also possible, from performance perspective this is a must. Even DML and DDL is possible (not advisable).
I think Mendix is lacking some serious Graph tools.
OQL can be very helpful to fill data sets, but only if they are context-sensitive for the Page they or on.
Flash is a thing from the past though....
With our IoT application we ofter want to shown 50.000 samples quickly. Does not work in Google, does not work in JSCharts.
Octave can do it, but has no Mendix integration.