OSM's learning curve is long indeed - its documentation is too disperse and hard to find (you have to know what you are looking for (wiki) before you can find it), but once you've grasped the basic understanding of how OSM works (mapping and tagging methods), things become pretty straightforward. I'm almost there now.

What most confused me in my reading/experimentation was the "relation" - it is used to describe both shape and association. Perhaps it is my using JOSM that helped in my confusion, but seeing a list of 'relations' consisting of unnamed multipolygons and all metro stations 'related' to the path of the metro line crossing the wee patch of land I was working on was indeed confusing - what is the use of a list if we don't know what those objects ~are~ ? Furthermore, keys (describing the point/way(/polygon)) seem to take secondary priority over the shape itself - In all logic, shouldn't it be the other way around? I think this is the hurdle that takes new users the longest to get over, and is the main cause of the disparity in placement methods of 'key' data. If I can cite a recent example, from my work on the city of Paris (France), contributors there added the "building" key to the "outer" polygon in a sometimes multipolygon, but not to the other multipolygon members, or the multipolygon itself: this means that someone rendering OSM data through his own methods would have to search the OSM data for a) a 'master' multipolygon, and if there is one, b) all polygon members of that multipolygon.

Even that didn't work out for me in some cases: contributors would sometimes make a building an "inner" polygon in a, for example, garden multipolygon: when I used the above method to try to make a comprehensive 'building' polygon, the result was the building being but a hole in the garden multipolygon.

Everything in a map is an object. A building, a tree, a patch of grass, an address - each has its own quality as far as data is concerned (a tree may be a node with a custom icon, a building could be a polygon or multipolygon, an address could be a node with a custom tag), but the form of the object should be ~secondary~ to its role, not the opposite!

Say I wanted to create a new object - a building, for example. In a 'new object' dialog, I would enter 'building', and perhaps any information about that building (owner, construction date, address, etc), then I would begin to draw it. The shape could be a polygon, a multipolygon, or a simple way (to imagine a 'glass wall' extreme case) - but this wouldn't matter! The shape, whatever form it has, would be connected to its 'parent object' through an id number. I know that this is just another way of repeating the OSM documentation "add keys to the multipolygon itself, not a member polygon", but presented this way it is much more comprehensive to the end user.

Yet a roadblock to implementing this method is OSM's method of storing data between 'nodes', 'ways' and 'relations'. I understand totally this schema from a data point of view, but this shouldn't even be visible to the end-user or contributor; for the time being key data can be attributed to ~any~ node, way or relation, and the data schema not only makes this disparity possible, but it promotes it.

Instead, what about an additional "object" element, one that would contain all the keys pertaining to that object (that would have its own id)? Each object's nodes, ways and members could still be distributed using OSM's existing methods (if the object's form was a polygon, the object's id would be associated with a 'way' line (itself having an id); were it a multipolygon, the object id number would be associated with a relation (itself having an id), then to member ways, then to way nodes... business as usual, what. I know that this 'object' is just an extra level on top of OSM's existing methods, but it would group all the keys under one 'data type', most probably making searches much faster (and fruitful), and possibly making it possible to divide data the data parsing workload between search and rendering engines. But most of all, I think this would make things much clearer and simpler for the end user!