I'd like to caution against falling into the common misconception about Design files vs CAM files. Eagle gives us a rich layering environment on the design files to give designers the flexibility to use them as they see fit. Because of widespread use of the tool, there has been some standardization of the layers beyond the copper and unrouted layers and as with any tool, if you are sharing designs, you'll have to agree on layer numbering. If you are taking open source and other "free" signs off the net, then it is up to you to make them fit your layering scheme. For 4-layer boards, I personally follow the 1,7,8,16 numbering scheme as that allows me to add additional signal layer pairs as needed, while keeping the ground/power layers in the core of the board where often times different weight copper or stackup is desired. It is not up to Eagle, nor would it be popular to take that flexibility away.
However, once you process with CAM, the notion of layers and nets goes away. Just as the design tool is an aid in creating your design, the CAM files aid various machinery in manufacturing that design. The CAM processor takes all of the layers you have chosen for a specific gerber/drill/etc file and "flatten" them into a single file describing aperture shapes and X,Y movements which is how photo plotters traditionally created the masks for board fab layers. The CAM generated files know nothing of your netlist, so if GNDA and GNDB are shorting together, it's because they physically overlapped on layers that were chosen for a single gerber file. You could even(and some do) include one of your silkscreen eagle "layers" in a gerber board layer and everything that would have been silkscreen would be in copper. If the SS overlaps the traces once flattened by the CAM processor, they conceptually become part of the net they overlap with and could potentially short to other nets, of course.
As far as different ODB++ "formats". ODB is not a simple file, even though it is contained in a single entity on your computer's file system. The DB in ODB stands for "Database". In other words, ODB contains a database of the equivalent contents of many files, including gerbers for all of your layers, and component position, rotation, z-height and other information needed for both PCB FAB as well as automated component placement and assembly(SMT). Gerbers are enough to make a bare board fab, but the pick and place machines need more info, for example to know how to properly orientate a diode so it's not backwards. Although ODB++ is standardized, I'm sure just like our gerber CAM processor, you can pick and choose which types of info you want included in the database. For someone simply ordering board fabs, they may just use ODB as a convenient way to have all of their gerbers + drill info in a single "file", similar to zipping, except the ODB also contains context that the machines comprehend, so they know a copper layer from a silk screen or mask.
Note that extended gerber(GerbX) is already a move in the database direction. The old "standard" gerber format(GerbD) required a separate file to describe all of the "Apertures" used in the separate gerber files. Apertures are sort of like the "Pen Shape" in a vector based art drawing program. That's why when you draw a line in Eagle with a non-zero width, it is actually 1*Width longer than specified, because the length is from the center of the apertures, which in most cases is a circular "pen" of radius = width/2.
Anyway, my conclusion, and many may disagree, is that there is nothing wrong with the existing Eagle layering system or the current CAM processing, other than the need to add the requested ODB++ capability. The dialog box for this would not be trivial as all of the information in the various gerber tabs would need to be entered, plus checkboxes for other info to include in the database such as centroid/rotation info.
Also note, that if ODB support is added, you'll all need to check your libraries to make sure they are IPC compliant, or you'll get complaints from the assembly house. Many and even most "Free" symbols I have found are not in the proper rotation, pin one marking, required by IPC. Even symbols that look correct may be wrong as you cant simply select group and rotate the group of pads to look correct. The symbol needs to look IPC correct with all of it's SMD pads showing as 0-deg rotation as shown by the info tool.
