let module::nested::variable = "hello";
That's not valid Rust.
To avoid potential confusion with the existing {:?} and {:#?} syntax for Debug and pretty-printed Debug output, the shorthand syntax does not support using {x=?} or {x=#?}. Instead, users should use the longer form x={x:?} or x={x:#?}.
The shorthand syntax also does not support custom formatting specifiers, such as {x=:.2}. In these cases, the longer form x={x:.2} should be used.
This makes the value of this feature for me nil. dbg! already prints the name and value of the variable. The only reason to use explicit println!/eprintln! calls is exactly because I'm not satisfied with dbg!'s choice of formatting.
This syntax is valid in any position where named arguments are currently supported, including formatting strings and write! macros.
Why? It's purely a debugging feature. What reason is there to support it in arbitrary formatting macros? I guess a possible reason is "it makes it easy to implement, because the format string can just be forwarded to format_args!", and that's fair, but the downside is that it can cause unintended bugs in downstream macros which have entirely nothing to do with println-debugging. That smells like a log4j design: let's introduce a reasonably sounding feature and implement it everywhere because why not? and then you deal with the fallout of unintended consequences.
I'm also concerned that the dangling = token can prove to be an issue in the future. It's really a formatting specifier, and it should go with formatting specifiers. Putting it with the spliced expression is weird, and may limit future evolution of string formatting syntax.
Given that this is a purely debugging-oriented feature, imho it's much more reasonable to propose an extension to the syntax of dbg!. It's already used exclusively for print-debugging. All other formatting macros, on the other hand, have a wide range of uses, and I'm very wary of introducing ad hoc extensions to their syntax.
If the issue is "I want to log this text to a file or send over network", perhaps it would be better if dbg! (or a related but different dbg_str!) could write its output to a string rather than stderr, so that the string can be written in whatever way applicable.