In order to really define "backward compatible," you'd have to define Arc in a way that's implementation-independent. In Arc, the code is the spec, so as soon as the code changes, compatibility becomes subjective.
For instance, suppose Anarki defines a new utility and uses it to simplify the implementation of 10 other utilities. (It does this in a few places.) Now suppose my Arc 3.1 code has defined a utility with exactly the same name, and running this code on Anarki causes those other 10 utilities to misbehave, thus wrecking my program. This is a case where Anarki isn't compatible with Arc 3.1, but since it's so easy for me to choose a different name for my utility, it's hardly even worth mentioning. Pretty much any substantial update to Arc would break it in exactly the same way.
There's only one difference between Arc 3.1 and Anarki that's ever gotten in my way, and that's the way Anarki has revamped the [...] syntax to support multi-argument functions. When I say [do t] or [do `(eval ',_)], Anarki treats these as 0-arity functions, and when I say [let (a . b) _ ...], Anarki chokes when trying to search the dotted list for any underscored variables. Once again, this is the kind of change that's pretty easy to work around, and I can't really say Anarki is worse for having this extra functionality.
I'd say Arc platforms are not really portable with each other, in the sense that not all code that works on one platform will work on another. However, I've found it pretty easy to develop my code so it'll work on multiple Arc platforms at the same time.
