Bill!
First I want to reassure you that if you want to stick to the 1.0 lib format, you can safely do that, we are not going to remove old library support. We already discussed that (in a google issue maybe? I can't remember), so I don't know why you're so concerned about that yet.
You're right about the fact that the library properties doesn't manage specific chips inside an architecture, we deliberately made this decision, otherwise we would end up with a structure like arch/[architecture]/[cpu] (and probably jantje would kill me :)), for example arch/avr/atmega328: this lead to massive code duplication since code for atmega328 is very similar to code for many other atmegaxxx, sometimes only a single line of code or a register name is different, and that can be handled easily with #ifdefs.
The same is not true when you move your focus from CPU to ARCHITECTURES: different architectures like SAM and AVR have very low code matching, practically null, and you end up using #ifdefs to select the whole file: in this case is much more clear and handy to use different files at all.
May we could extend just the .properties file to say that a library runs only on a specific chip? so for example a library for a 32u4 would not be listed when the selected board doesn't have a 32u4? Maybe.
We could extend that also to the examples? Maybe.
I would like to see a proposal from you on how you will do that.
These are all things that can be added (also later) to extend the capabilities of the library specification. BTW, this is all parsing work that will go to the back of tools-maintainers too.
"dependency" and "dependency-core" are placeholders for the future library manager. The version specified in the dependency-core is the version of the CORE (and not the IDE as you presumed, even if they are still coupled). You can find the core version inside the platform.txt file. As you can see those fields are just drafted and there is room for improvements here when the library manager will be put in place. I'll make an announcement on the developers list when we start to define it.
At the moment the IDE doesn't enforce dependency check on those fields. I'm happy to see how you would improve that, consider that they are mainly focused for machine-dependency check on the future library manager.
About compatibility of 1.5 library with IDE 1.0: its true, but again, how would you change the specification to allow that? See that there is very small room for improvements on the old lib-1.0 format.