Moblin compliance specification should define deprecation policy that, actually, is a part of Moblin backward compatibility promise. One of possible variants of the promise can be as follows. The Application Binary Interface described in the Moblin compliance specification is guaranteed to be available in the next release of the platform except for deprecated elements. That means any Moblin 2.0 compliant application will work at any Moblin 2.1 compliant distribution if it do use only functionality that is specified in the Moblin 2.0 specification and that is not marked as deprecated. This example of promise is rather weak, but in my opinion it is good enough for the initial stage. But, of course, Moblin developers are who have to define their promise to ISVs.
May be for Moblin 2.0 it is ok to not promise backward compatibility at all? In this case an ISV have to recertify his Moblin 2.0 compliant application for Moblin 2.1 and possibly even to fix and rebuild it. At the same time, the compliance specification provides the common denominator for all Moblin distributions of the same generation. Benefits of this approach are as follows: 1. The issues with unstable clutter libraries are easy solvable. 2. The specification is so big that we cannot make sure it includes stable ABI only within reasonable time. Flexibility to modify the next version of the specification in incompatible way is very pleasant in these circumstances. Later we will be able to introduce backward compatibility promise if required.