Looks like commit of key names is waiting until focus is lost or enter is pressed, but still noticing that creating a duplicate key will overwrite the existing key, versus rejecting the new key or forcing a rename.
Build b2019020502
Before:
After:
Yeah, I would call this not fixed. Duplicate keys should not wipe out the prior property.
I’ve opened an internal ticket for this one. The fix to defer updates is actually doing what it is supposed to - this is just a side-effect; originally, a key was written to the View after each key press (which is why you had an instant collision), which no longer happens. The fix for the key deferment did not include any acceptance around preventing name collisions.
2 Likes
This issue was fixed in the build that was uploaded today (3/1).
Please let us know if you continue to see this behavior after upgrading.
1 Like
Looks like this is 99% of the way there!
Works for everything except when you leave the key name as key.
Inserting a new key with and existing key name key causes the same collision as before.
Other than that, solved 
Build b2019030102
1 Like
Yes, we already opened an internal ticket for that scenario, but thanks for validating my findings!