Keyed list entry builder should cross-reference keys and their constituents

Given the simple model:

list lst {
    key key;
    leaf key {
        type string;
    }
}

generated entry lifecycle is a bit weird, as it is possible to create a Lst which has a mis-matching key() and getKey(). This is because key() is a separate "property", as that allows sharing a single object across copies - but key constituents are not cross-referenced so that the key is reset when a conflicting leaf is stored.

Design and implement an efficient way of cross-referencing the two, so that users do not get surprises.