Ok, resurrecting the thread, I'd like to propose another way to specify this. The end result should be very close but should provide a simpler, clearer mental model.

Every expression has now has a lifetime associated with it, and can be marked as "scope". It is only possible to assign b to a if b has a lifetime equal or greater than a's.

An infinite lifetime is a lifetime greater or equal than any other lifetime. Expression of infinite lifetime are:
 - literals
 - GC heap allocated objects
 - statics and enums.
 - rvalues of type that do not contain indirections.
 - non scope rvalues.

Dereference share the lifetime of the dereferenced expression (ie infinite lifetime unless the expression is scope). Address of expression shared the lifetime of the base expression, and in addition gain the scope flag.

Comment: Using these rule, we basically define any indirection being of infinite lifetime by default, and we propagate the lifetime when scope. The addition of the scope flag for address of is necessary to disallow taking address->dereference to yield an infinite lifetime.

Variables delcarations (including parameters) have the lifetime of the block they are declared in (2 pitfalls here, I don't have good solution, and the original spec do not as well : #1 destructor, finally, scope statement and #2 closures). Use of these variables shared the lifetime of the variable, unless they qualify for infinite lifetime. Parameter's lifetime are unordered, meaning smaller than infinite, greater than the function's scope, but not equal to each other nor greater/smaller than each others.

Working from there, I'd like to define properly the pitfalls #1 and #2 . These are the great absent from what is discussed so far.

const scope works for Rust, but isn't gonna fly for D. That is a good idea, but not worth the cost.

I'd like to discuss the pro and cons of such a definition (compared to rust for instance):
 - We can't specify explicit lifetime for parameters. I'm not sure how limiting it is. This is something we can extend toward anyway in the future, so I suggest we put that aside for now.
 - We can't define lifetime of indirections explicitly. This clearly limit the expressiveness compared to Rust, but I it allow for scope to be a storage class rather than a type qualifier, and I think this is a winner when looking at the complexity / expressiveness ratio.
 - In D, mutability and burrowing are decoupled, which i think is a plus compared to Rust. That prevent us to go for things like the proposed const scope, but simply the concept of both mutability and burrowing in D, while allowing some pattern that aren't easy to get in Rust (multiple writable reference to one object in a single thread for instance, is trivial in D).

Maybe I'm convincing myself, but I think we have a winner here.

Andrei, what do you have in mind when you say scope should be the default ? I do think this is a sensible default, but I fail to see how this is gonna translate with existing code in a nice manner.