By that logic, I could port all my Windows 7 applications to run in DOS and get all my Xbox 360 games to run on an original Xbox.
True. With this, though, we have access to Android's source code (ah, how I love open source), this makes it easier. There are 2 options for a new version, the first is when something in the public interface has changed (i.e. a return type of a method is different --- either object or value), or you've added features.
If the changes are all adding features, then the version numbering then becomes a marker to say the feature set that these things are able to work on.
If, however, the changes are to do with the public interface, then I'm sure that they're not going to have removed the functionality without providing a replacement. The task then becomes, figuring out which calls still work, which don't and then how to use the API to emulate the ones that don't.
The main problem is time, if someone were to go to the effort of porting this stuff, you'd be months behind Samsung. So, if and when they release the updates all that effort would be effectively wasted.
The problem are not 1.5 applications, but 1.6 applications that are not backward compatible to 1.5 (which is only few months older than 1.6).
Mostly this comes down the poor programming on the application's side. They should be able to isolate the parts that require the functionality of the higher SDKs. I was looking at AndNav2, and (unsurprisingly) it didn't work because it required 1.6's text to speech. If the developer had coded it so that it disabled that feature and informed the user, then it wouldn't have been a problem.