Multi-select and Feature List
In early iterations of the data editor, the UI consisted of a feature list on the left, and a map view on the right. In the list every feature needs a unique identifier. This introduces a problem because a concept like "name" does not exist in GeoJSON. Creating such a concept adds significant implementation burden.
Another problem I tried to tackle here is editing the fields of multiple features at the same time. Similar to "names", the concept of "shared property fields" also don't exist in GeoJSON. Every feature can have a list of different property fields.
The question is if we want to adopt a UI that's similar to the GeoJSON structure, or diverge from it more dramatically. We took a step back and did a few user testings. We discovered that "names" don't really help people find what they are looking for. They usually associate one feature with multiple properties and its actual location on the map. Tom suggested removing the list design and simplifying the UI to focus on the main tasks: draw, import and edit.