LOD is a case of multiple representation, where you want to associate some extra meta-data so your application can decide which representation to use.
Depending on the algorithm your application use you may need more metadata than just the LOD level, some may use a distance from a bounding sphere, or a projected surface or many other parameters to decide which alternative representation to be used.
Selecting different representation based on the target platform for instance is no different (use this model, or this set of models on PS2, and those on PSP, and those on PS3…). Or selecting different precomputed T-meshs with different optimization parameters.
By design, COLLADA need to be able to handle all the data and metadata necessary for this purpose, but will not mandate how the data is to be used. In other words, if a tool does not know what LOD are, it can still let the user select which representation the user want to edit…
Making this selection at the <mesh> level is one possible way, it has the advantage of referencing any of the representation with a single geometry id. But sometime it is too low level, since the selection may require using different material as well, so you can use a simpler FX when the object is in lower LOD, or when the target platform does not accept shaders… In that case the selection should be done at the <node> level in the scene, or maybe at the <instantiate_scene> level, since the multiple representation choice could be done for the all scene.
<mesh> has already some extra data. So you can already use this to store the meta information you need. In the modeler, the extra data should be available as ‘user property’ and exported/imported in the <extra> of the <mesh>, so this should work transparently.
<geometry id="mygeom-lib" name="mygeom">
<level> 0 </level>
At the node level, the selection can be done by using several <instance_geometry> and adding the proper information
<level> 0 </level>
In regards to design, selecting from various representation is a hierarchical asset management issue. You would like to be able to collect all the representations of a given model (parent asset), you would like to know if there are some dependency between the assets (this model was computed from this other model, with this tool …), or what tool and source data was used to create the given representation.
<extra> element can have a <asset> element. This can be used to check the creation date and modification date, which tool was used to create this particular element, and so forth.