They say they are feature backward-compatible (because someone who already implemented software doesn't necessarily have to change it), but they aren't process backward-compatible because they change the scope covered by the individual documents.
So you can define your tool as being compatible with NIPS 771, 168, and 490, but not with any others. But if they then move sections from 771 to 107 and from 817 to 771, then you're not compatible with 771 or 817.
That's why someone who creates an SDK suffers most, because he can't use the NIPs effectively to define what his modules actually do, so he has to version his SDK with a particular configuration of the NIPs.
He can't just say "I conform to the mandatory requirements of NIP 771." because that might be a completely different document covering a completely different topic... tomorrow.
And he can't plan the implementation of NIP 14, 15, and 231 because those NIPs might
- disappear,
- be rearranged,
- be sliced and diced and
- have their content spread out to other NIPs, or
- be completely rewritten,
by the time he gets around to implementing them.
Even if it's only a matter of weeks.
Our SDK will be clearly versioned and conform to a particular configuration of NIPs, as defined by us.
Any changes, including breaking changes, will be implemented in new SDK versions covering a new NIP configuration, as defined by us.
