QML value type write-back support is inconsistent

QML has the concept of value types which in theory should always be passed by value rather than by reference. Yet, as JavaScript is fundamentally built around references, this leads to confusing behavior. For example:

Text {
    Component.onCompleted: font.bold = (some * complicated * expression)
}

Here, if font was a pure value type, we would retrieve a copy of it, store on the JS stack, set the "bold" property on the stack copy, and forget it. Obviously that is not what the user wants.

In order to work around this issue, value type references have been invented. A value type reference keeps a copy of the value, but also knows what property it was retrieved from. When the value is modified, it is written back. Now we get a different problem, though:

Text {
    Component.onCompleted: {
        var f = font            // creates a value type reference
        f.bold = true          // writes back
        otherText.font = f 
    }
}

Here, the user did not want to write the value back. Rather, they wanted to pass a slightly modified font object to a different Text element.

Furthermore, the write back mechanism only works across one level of property access. This makes it impossible to modify value types held in a container or nested value types.

A solution would be to

1. add recursive value type write back.
2. drop the reference and only keep a standalone value type object if the value is declared as a var, let or const in JavaScript, or when it is passed as argument to a function.

This requires changes to the byte code format. So far we don't always record whether a register represents an explicitly declared variable in JavaScript or a temporary part of some expression.