Backwards-compatibly changing existing features feels qualitatively the same to me as adding new features. In either case you can ignore them until you need to work on a codebase that uses them.
At least in Rust, capture granularity is per-variable, so I think closures don't contain a stack frame pointer? Though, I'm not sure why this would matter to a user evaluating Rust's closures vs. D's nested fns?
Saying library authors are content with their absence is probably a bit too strong. There's not really another option, and I doubt many folks would choose not to author libraries for this reason alone. I personally have found their absence annoying when writing Rust libraries.
I'd probably be in favor of a hard cap on # of function arguments. :)
What's it like working with Rust full-time? Is it similar to using any other language for a job? Do you find yourself enjoying coding more? Do you get unnecessarily caught up in micro-optimizations for things you wouldn't blink at in Go/Java?
Every language has different idioms. In many cases, what works in C++ doesn't work in Rust. Generally, anything the book says is bad you should take as qualified to mean bad in the context of Rust programming, not programming at large.