State of Macros 2.0

## Merged RFC
https://github.com/rust-lang/rfcs/pull/1584

The RFC PR concluded with a [summary and statement of intent by @nrc](https://github.com/rust-lang/rfcs/pull/1584#issuecomment-276869526) to add a new declarative macro system to Rust. No details were specified except for the use of the keyword `macro` or `macro!`, opposed to the currently used `macro_rules!`. Those macros shall work by desugaring the macro syntax into the underlying mechanism for macro expansion, which was not specified yet.

There was also some contention about how to name the new macro system. The working name in the RFC by @nrc was "declarative macros". His reasoning was that it shows the contrast to procedural macros, promoting the fact that these macros are defined using declarative syntax rather than Rust code. They preferred "declarative" over "pattern" since this leaves room for possible future declarative macros which do not rely on pattern matching so centrally.

## Tracking Issue Declarative Macros
https://github.com/rust-lang/rust/issues/39412
As far as I could determine, the tracking issues task list is pretty up-to-date. This means that, at this time, the following tasks/questions are still outstanding:
1. Implement "[hygiene bending](#hygiene-bending)" for when users want a name from macro def to "escape".
2. Implement inter-crate hygiene for nested macros (pending macro def encoding).
3. Make `private_in_public` hygienic?
4. Make `unsafe` and lints hygienic (if appropriate)?
5. Future-proof matchers (e.g. `$e:expr`) by employing a simpler, more general grammar.
6. Allow fragments (e.g. $e where $e:expr) to be parsed in more contexts (c.f. [Macro matching is incorrect for macros invoked in macro expansions #26361](https://github.com/rust-lang/rust/issues/26361)).
7. Decide whether we want macro invocations in identifier positions and/or eager expansion.

### Hygiene bending
Hygiene bending refers to the ability to "expose" identifiers defined in the macro body in the scope where the macro is used. With macros 2.0 this is not the case by default, since they implement "def-site hygiene". Bending the rules of def-site hygiene are sometimes desirable.

An issue with an example use-case and associated discussion is shown [here](https://github.com/rust-lang/rust/issues/91249). Some insightful comments in that issue:
- [What does hygiene mean for a reference through a qualified name?](https://github.com/rust-lang/rust/issues/91249#issuecomment-980813146)
- This and the following comments argue for a distinction between scope of bindings and the names of exports.
- [Motivating example for hygiene bending](https://github.com/rust-lang/rust/issues/91249#issuecomment-981264722)
- This comment shows that scopes of macros behave differently than scopes of modules, and that this behavior has to be adjustable via hygiene bending.
- [Argument for the current behavior, together with hygiene bending](https://github.com/rust-lang/rust/issues/91249#issuecomment-988333420)
- [A proposal to use the `export` keyword to make items visible outside of the macro body](https://github.com/rust-lang/rust/issues/91249#issuecomment-1194143586)

    pub macro generate_class_new($name: ident) {
        pub struct $name {
            x: i32
        }

        impl $name {
            pub export fn new(x: i32) -> Self {
                Self { x }
            }
        }
    }

The implementation of hygiene bending depends on

### Inter-crate hygiene for nested macros
Inter-crate hygiene is already implemented _except_ for nested macros. [This comment](https://github.com/rust-lang/rust/issues/39412#issuecomment-615451116) mentions cross-crate hygiene as a prerequisite to implement `Span::def_site`.

## Tracking Issue Procedural Macros
https://github.com/rust-lang/rust/issues/54727

[This comment](https://github.com/rust-lang/rust/issues/39412#issuecomment-1727033834) by [@petrochenkov](https://github.com/petrochenkov) asserts Declarative Macros to be syntactic suger for Procedural Macros. This implies that Procedural Macros have to be implemented before Declarative Macros can be finalized.

Sadly there is not much information about the current state of the issue to be found in it as far as I could discern. A [request for a summary](https://github.com/rust-lang/rust/issues/54727#issuecomment-1150179925) by [@joshtriplett](https://github.com/joshtriplett) was left unanswered, but mentioned `Span::def_site` ([tracking issue](https://github.com/rust-lang/rust/issues/54724)) as one un-stabilized item.

## Tracking Issue Span::def_site
https://github.com/rust-lang/rust/issues/54724

This seems to be the current item that blocks progress on Macros 2.0. [@nikomatsakis] requested in [this comment](https://github.com/rust-lang/rust/issues/54724#issuecomment-1143955602) "some kind of docs about the intended effect that can be reviewed". As far as I can tell, this request was not yet fulfilled.