Document that mixing array syntax with other forms of populating default properties produces undefined ordering

Let's define a QML component Foo with a default property - file Foo.qml:

import QtQuick 2.0

Item {
    default property list<Rectangle> kids

    Component.onCompleted: {
        var k = Array.from(kids);
        for (var n = 0; n < k.length; ++n) console.log(k[n].width)
    }
}

But what happens when you have children (= nested components) as well as an explicit binding to the default property? Like this:

Item {
    Rectangle { id: one; width: 1 }
    Rectangle { id: two; width: 2 }

    Foo {
        Rectangle { width: 3 }
        kids: [one, two]
        Rectangle { width: 4 }
    }
}

With the QML compiler, the explicit binding always wins - the output is qml: 1; qml: 2, regardless of the ordering of the three lines in the Foo instance.

With the QML interpreter, however, the children (all of them!) win, unless the explicit binding comes after the last child. The output of the above is thus qml: 3; qml: 4. Note in particular that even though the width 3 rectangle is removed as child when the explicit binding comes along, it is then resurrected by adding the width 4 rectangle to the implicit binding.

In my project, I was always using the QML compiler, and at some point figured out that an explicit binding overruled the assignment of children. Henceforth I felt free to overrule  the assignment of children to the default property with an explicit binding where convenient. Then last week the (by then substantial) project required me to switch to interpreted QML, and all hell broke loose.

Although the result of mingling children and explicit bindings to default properties does not seem to be officially defined , there are several concerns here:

1. As it's easy to do and potentially useful, the result should be well-defined, one way or another.
2. The claim here that creating a child item "has exactly the same effect" as explicitly binding it to the default property is demonstrably false.
3. That the behavior of the QML interpreter here depends on where (within the same context) a binding is declared does not fit the semantics of the language at all.
4. In any case, the result should not differ between QML interpreter & compiler, as this has great potential to introduce obscure bugs when switching from one to the other.

Cheers