From a consistency perspective, option 3 would be the best! Why isn't that a good idea? Because its hard to implement? I can understand that it's a nuisance to create an XProc processor that must support both...

I think we should at least allow 3.1, so option 2. Whether (if we don't do option 3) version="3.0" actually does 3.1 could be implementation defined, yes. Still, it will be confusing.

There are only a very few, small changes between 3.0 and 3.1. I don't think you're suggesting that a 3.1 processor should reject, out of hand, any pipeline labeled 3.0. So you must be suggesting that a 3.1 processor should also handle 3.0 pipelines. But then we need to define rules for what it means if a 3.0 pipeline imports a 3.1 step, and vice versa. It's impractical to have different declarations in scope for steps in a 3.0 pipeline vs steps in a 3.1 pipeline. It's not impossible but it is absolutely not worth the (significant, IMHO) effort that would be required.

I think it's easier to say that a 3.1 processor may load 3.0 pipelines and then pretend they were labeled 3.1. But if you're going to do that, would it be better to just leave them all labeled "3.0"?

How about this:

An XProc 3.1 processor must accept pipelines labeled with version "3.1". It may but is not required to reject pipelines labeled "3.0". If it accepts pipelines labeled "3.0", it must process them as if they were labeled "3.1".

This:

1. Allows users to run pipelines labeled 3.0 without being forced to update the version
2. Assures that 3.1 implementations will treat pipelines labeled "3.0" in a consistent way.

Is it possible to construct a 3.0 pipeline that won't work correctly in 3.1 with these rules? Perhaps, but we have good reason to believe that no implementation will ever reveal this.