Great question, and I'm not 100% sure.  We should always always always back-compat test changes.  This needs to be part of the automated QA system.

I didn't test this, but I don't believe it would.  The code that use this output would be able to unserialize (no assumptions about the particular fields there), and they pick and choose particular dictionary keys (so ignore unused fields).

Is that good enough for the moment?

Also, I was thinking about this the other day: though we ALWAYS want to try and avoid adding features that will break back compatibility, sometimes it's worth the tradeoff.  In order to make things still work, perhaps we should create a branch where we ALWAYS send the KALite distributed server version in any securesync request.  That way, when we have a non-back-compat way to do something, we have a way to set up an exception on the central server side.

If we used it a lot, it would make code really really difficult to read.  But used sparingly, I think it's powerful and important.  Even if we chose NOT to ever use it in an if...else, we would be able to see what versions of KALite are pinging us, which is in itself useful.

I'll add a trello card for this.  I think it's worth the effort.