QUOTE
I do empathize with Chuck, though, as I tried to open a project created in v15 in my v13 CD version but could not, as files are not backward compatible.
It's something of a thread drift to delve too far into this idea of backward compatibility but since the issue has been raised here we might as well address it here.
A:M is highly backward compatible (it gets a bit dicey when you get back into the v8 timeframe because so many things have changed but even there most of the files are backward compatible because A:M v16 can easily read them). It is the
forward compatibility that is problematic in that it is near impossible to predict, plan for and implement programming for changes and processes that will be made in the future that do not yet exist. File formats such as the one implemented in v13 certainly help in making the forward compatibility planning process easier. That makes it easier to spot the breaking changes that will inevitably occur with the addition of new and innovative features, to plan those accordingly and to help users adapt to those changes.
This is an entirely understandable and logical problem to people that take the time to think about it.
The problem arises when people have expectations that clash with reality.
Bear with me a moment here as I try to explain.
A classic example of this might be an older version of Microsoft Word. Now consider that we are talking mostly about text and images here... something that it would seem would be highly transferable from one version to the next. When a new version of MS Word is released that necessitates a change in the file format itself or when additional information from a particular feature is stored within the file, there is no way that the older version can interpret that information. The best it can to is approximate or ignore the information. Most of the converters that are available for older versions of Word do a pretty good job of 'recovering' the important information but in several cases it took years for those converters to be made. I submit to you that they were finally made because someone on the sidelines saw the problem as a challenge and set out to program the thing and eventually the converters were widely shared. Keep in mind that there is also a huge user base behind MS Word and perfect conversions when going back to older software still aren't made. (For a modern day equivalent look at some of the incompatibilities between Google Docs interpretation/conversion of MS Office files and Microsoft's attempt to use that as a selling point to get people to switch to MS Web Office (or whatever they are calling it these days).
So if Microsoft can't do it, what are the options then with A:M?
Well, firstly and foremostly most of v16 files should be largely compatible with v13. (If you start a topic that focuses on the incompatibilities you are experiencing much could be learned about the thing. Just understand that the easiest solution, and therefore the one most likely to be suggested, is going to be an upgrade.)
The problem with
forward compatibility appeared circa v12 because that is where the whole structure of A:M file formats changed.
In most cases A:M now warns us when updating older files to current versions to keep us from opting out of forward compatibility.
The old program, in your case v13, cannot see into the future so it can only read files the it wasn't programmed to read.
Luckily for you you didn't say you were using v12.
While it is possible for some programmer to (in effect) time travel back to v13 and add capabilities to it (via a converter) it will be cheaper for you and for the programmers and for the community to just upgrade to the current version. Then there will be no incompatibilities.
So, while I know this is the whole issue at hand and the cause of much frustration, the solution is simple. Upgrade.
It is far more economical for two or three guys with the need for forward compatibility living four years in the past to upgrade at $79 than for programmers to program a utility that 'technically' no one needs. As you explore the problems with supporting people that are 'saving money' by using older software you start to see more and more absurdities.
Martin Hash is a smart guy and in hindsight I see that while his move to the websubscription was largely for more practical reasons and a tough decision to make, the subscription also addresses this issue of file version incompatibility across versions. When everyone is using the current version there are no (as in zero) incompatibilities.
What is amazing to me is that every time someone complains* about the subscription I get another chance to see a new aspect of Martin's genius.
I realize there are many who have closed their minds to this and refuse to hear it but I have don't expect to alter their opinion and I have very little ability to effect reality. The best I can do is suggest talking through the problem until the way forward becomes clearer.
*I don't use the word complain in a negative sense here although I recognize that most do. For what it's worth, I see complaints as a useful feedback mechanism that brings the user's experience back into the system where it informs future decisionmaking. In this sense we need more unhappy people that are willing to complain!

Of course, it always helps when we have a fairly good grasp on reality on which to ground that complaint.
Another thing I should mention is that because A:M's file format it text based (and since v13 is a near XML format) everything from v13 onward is highly backward and forward compatible but the average user won't know how to interpret the text of those things that aren't. I would recommend hiring someone to interpret that text but the time it would take that person to perform the task would cost considerably more than a subscription/upgrade.
Hope that makes sense.