But I also want my users to be able to update from version 1 - 5 directly, 2 - 4, 3 - 5 and so forth.

Schema upgrade in DO is generally designed to upgrade the data from precisely known version to the current one. So in some cases it will be possible to upgrade to v3 from both v2 and v1, but in general case - no.

In general case you need incremental upgrade routine to handle this. Imagine user upgrades your application from v1 to v4:

• When your application starts, DO discovers it can't build a Domain (upgrade handler of v4 detects there is v1 instead of v3, so it can't upgrade the data), and you get a specific exception.
• You launch a special upgrade routine, that sequentially launches Domain.Build() for v3 (fails), v2 (succeeds with upgrade), and v3 again (succeeds with upgrade). All these Domains are build in dedicated AppDomains, since you must load different versions of model assemblies for this.
• When this process completes, you can rebuild the domain.

To implement this, you should:

• Maintain a directory (e.g. "Migrations") with all the previous model versions of your applicaiton (i.e. with "v1", "v2", ... subdirs).
• Use some convention allowing your upgrade tool to build a Domain based on assemblies in each of these folders. E.g. it can simply look for some specific type and method there (DomainBuilder).
• And finally, write the upgrade routine implementing this logic (i.e. iterating over directories and launching the code based on convention in dedicated AppDomain). Likely, we'll implement such a tool in future.

So the same upgrade steps should be performed on the exported database file before the data is added to the main application database file. Again, is DO smart enough to detect from which version to start, and in which version to end?

No, DO can't do that, and moreover, there is principally impossible. DO uses a specific set of rules on upgrade and doesn't have any history of changes of your model, so it can't do this. I.e. if you rename A to B in v1 -> v2 with data loss, and rename B to A back in v3 (again, with data loss), upgrade from v1 to v3 directly will lead to different result then incremental upgrade. So I'd advice you to use incremental upgrade.

Btw, default upgrade handler (see UpgradeHandler class) reports it can upgrade the data from empty DB, or from the same version:

public virtual bool CanUpgradeFrom(string oldVersion)
{
  return oldVersion==null || oldVersion==AssemblyVersion;
}

But since normally you don't explicitly specify the schema version (i.e. use default "1.0.0.0"), no error occurs even if you change your persistent types.