This will have different output than the before, since backtick will html encode its content in current D (both implementation and spec) and `$(D ...)` does not. So the former will actually output `<= character` and the new will show, to the end user, as `&lt;= character`. You can't use html entities or tags inside the backticks.

Again, it shouldn't be $(D $(LREF)) nor LREF backtick, it should just be plain LREF.

Now *this* is a clear example of what I was talking about above: why wrap LREF in any kind of code macro, D or backtick, when LREF is already specifically referring to code? It should just output the appropriate thing to begin with and not have any wrapper.

I'm also of the opinion that explicit links should not need to be wrapped in anything. If you find yourself always writing `a(b(c))`, then define `d(c) => a(b(c))` and use `d`... which is what it is actually doing here, but it is repeated work on module level from one of the global macro definition files. I guess that's a separate issue from this PR, but these local ref macros should all be replaced with one of the generic ref things, that can style the text in the monospace font using a specific class name rather than wrapping the two macros together.

Now, this is a case where I don't think it should have been `$(D ...)` to begin with - this is json, not D, so it should have been using a generic code syntax. But you can't really automate a decision like that.

notice the backticks inside that...