And that therefore, if I want to create two (or more) transactions from a watching-only wallet, such that both are spendable without conflicting with each other, then it's my responsibility to use coin control to ensure they spend from different addresses?
Yes. I do that sometimes. It works fine, if you are careful, but if you use the same input twice you cannot broadcast the second transaction (and do not get a clear error message).
We took the easy way out on this topic (and didn't address it), because the alternatives are more complex under the hood and in the UI. If you allow Armory to arbitrarily lock inputs from being spent on subsequent transactions, you have to somehow represent to the user the state of the "locks" on your wallet. This includes some super-arbitrary amount (even though your tx is 1.3 BTC, you have 21.32 locked), and it also leaves open confusion when you end up not signing the transaction (changed your mind, made a mistake in the original and want to recreate it, etc) and now you have coins that are locked unnecessarily and you need to be able to reset the lock state. If it's not represented clearly, then you have new users who say "what's this Create Unsigned button do?" and they end up with locked coins and emails to us asking why fund are inaccessible.
If there was at least a way to create a tx for X and then always lock exactly X, that would make it reasonable. But in most cases you have to lock some unexplainable amount more than your transaction is, and in some cases it's just not possible to do multiple offline tx (if you only have one input).
At the end of the day, if you need to create multiple simultaneous offline transactions, you should be sophisticated enough use coin control and understand the limitations. On that note, we should have an input-level coin-control interface... soon...? Stay tuned.