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. :)