Looks like you've accidentally replied only to me, not the whole list.

> Verbosity is solved by:
> ``[[doc::brief("..."), doc::param(...), ...]]``
> since we can combine attributes, but also the doc::xyz doesn't have to be the final name, it's just a suggestion for this thread.
> We could just as well end up with [[brief(...), param(...), return(...)]] which is actually less verbose than existing doxygen syntax.

It's not less verbose, no. It's

> * @brief Abc.

vs.

> , brief("Abc.")

Even without the quotation characters, it's not any shorter. I would
also be quite concerned with how well auto-formatters can handle this.

Furthermore, it would be bad if there was no std:: or doc:: or
whatever namespace in front, since you would be introducing a lot of
new names, and you would want to clearly indicate that these are all
documentation attributes with no semantic effect.

Why are you so attached to attribute syntax anyway? We've been using
doc comments in various languages just fine for 30+ years, but
suddenly, we need to invent a new system?

> And for the point of a "technical reason", what was the technical reason for the inclusion of the deprecated attribute(N2236)? or P2573? The later even explicitly says motivates the standarization of `=delete` messages with the following dialogue
>
> > The library author is saying, "I know what you’re trying to do, and what you’re trying to do is wrong. However, I can tell you why I think it is wrong, and I can point you to the right thing to do."
>
> That's not a technical reason. The prior method was something like
> ```cpp
> // reason for deletion
> function =delete;
> ```
> moving from that to
> ```
> function = delete("reason for deletion")
> ```
> is functionally identical to what I'm proposing, just through attributes.

What you're proposing is equivalent to a comment, just with different
syntax. Adding a reason to "delete" lets you incorporate a string into
the compiler's error messages when you call a deleted function. What
you're proposing is purely adding commentary on top of code, which
could just as well be located in a comment, or in a separate file, and
which is not used by implementations in practice. To my knowledge,
there is no compiler that uses Doxygen comments in its diagnostics.