I wonder if the examples bit shouldn't come after slices, as its own chapter.

This is a great start! Some initial thoughts:

• The transition from the fn-based example to the block-based example was jarring. I think the text it best-served by staying with the fn example, which has a strong intuition. Then you can come back later and talk with more precision about how long borrows last and what happens when they go out of scope.
• For mutable references, you mention the rule restricting aliasing, but you don't provide a motivation. I think it's really good to try to include an example of how aliasing + mutation gets you into trouble. Happy to help brainstorm here.

Rust’s references must always be valid. In other words, if we have a reference to something, it must not go out of scope before the reference does. Dangling references are a pervasive problem in languages that support them.

I think we should reframe this as: In languages with pointers, it's easy to crate a "dangling pointer" by freeing some memory while keeping around a pointer to that memory. In Rust, by contrast, the compiler guarantees that references will never be dangling: if we have a reference the something, the compiler will ensure that it will not go out of scope before the reference does.

• I think we will want to add material on:
  • The notion that borrows have a "duration" (i.e. a lifetime, but we can avoid the syntax)
  • The fact that, for the duration of a borrow, the original object is inaccessible. But after the borrow expires, you can access it again.

And, as I said before, I think we want to spend a bit more effort trying to motivate the various rules (but hopefully can do so without major digressions.)

I've updated a few things.

For mutable references, you mention the rule restricting aliasing, but you don't provide a motivation. I think it's really good to try to include an example of how aliasing + mutation gets you into trouble. Happy to help brainstorm here.

What about @Manishearth's post: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ maybe one of these?

I think we will want to add material on:

• The notion that borrows have a "duration" (i.e. a lifetime, but we can avoid the syntax)
• The fact that, for the duration of a borrow, the original object is inaccessible. But after the borrow expires, you can access it again.

I thought this was sorta implied by the 'dangling' section, but maybe it could be its own section too? Or dangling would be a sub-section of it?

I'm going to merge this for now, and we can come back to clean up the details later. Worrying about this is blocking me moving forward, and the details are all fairly minor. I'm going to open up individual issues for the stuff that's not been addressed.