QML console object implementation is not compliant

Summary

The deprecated console.exception() function's behavior is not conformant with neither console Standard, MDN docs nor Qt itself.

Description

In QML's global scope there is a console object/namespace which partially implements "console Standard" plus Qt extension regarding LoggingCategory QML Type.

The console.exception() function is obsolete and removed from a Living Standard; it is marked as a deprecated alias for console.error() in Mozilla/MDN documentation; and it is implemented differently in Qt.

1. In Qt, console.exception() prints a stacktrace, which is cool and all, but there should be actually is a dedicated and standardized trace() function instead — except it should support data arguments too (which it currently doesn't).
2. In Qt, the most severe logging level is QtFatalMsg, and it is the one with a power to instant-kill an application (after writing a dying message, that is). Since exception and error are different, and error corresponds to QtCriticalMsg which is the last before QtFatalMsg, therefore it would be reasonable to expect the former to be equivalent to QtCriticalMsg and shut down an app. Instead, there is no built-in method in console namespace to do that.
3. Even LoggingCategory QML Type can't help. It's defaultLogLevel property is confusing, and probably not what you thought about at first: it is a filter, not an actual level with which to log messages by default. I honestly expected "non-leveled" functions print and console.log to use that level as default, but only after browsing Qt source code I understood what it's really all about.

Suggested solution

Support same data formatting/printing in trace as everywhere else.

Get rid of obsolete console.exception() function, at least for the sake of reducing confusion and increasing compatibility with standard.

I don't see how console could be extended to support fatal messages from QML, without introducing new standard-breaking extentions. But it might be a nice addition, at least for feature-parity with C++ API.

LoggingCategory::defaultLogLevel should've been named defaultFilter or something. But I'm afraid it would be considered too much of a breaking change.