CI doesn't like this, I'm not sure why. Is there a trick needed for these?

┌ Warning: no doc found for reference '[`@info`](@ref)' in src/base/base.md.
┌ Warning: no doc found for reference '[`copy!`](@ref)' in src/base/base.md.
┌ Warning: no doc found for reference '[`⊉`](@ref)' in src/base/collections.md.

Possibly not the canonical name for it? Often they are [@ref Base.copy!] and such

Alternatively they are not included in the manual. For example @info does not exist, it is only documented as the generic @logmsg

Thanks for the hints. I'm slowly ironing them out locally, a few more builds to go.

I couldn't make a reference to @logmsg or Logging.@logmsg, but could make a reference to Logging which might be narrow enough.

Questions:

• Can I include references from Base to functions in standard libraries somehow, or is that impossible? At the moment I just reference the library itself, or the heading of the manual section. That's more useful for @printf than for LinearAlgebra.
• Can I refer to labels like kw"?" for the ternary operator, or kw"&&", from other docstrings? I think I deleted my attempts from the present state of this.

It would be great to get this in.

Excellent, what needs to happen, do you think?

• Some functions are newly documented, i.e. added to doc/src/base/.... Maybe that's a review priority, does this make them more official? I'm not so sure of the policy here.
• I'm still unclear how to create some cross-links, if anyone can enlighten me on Add many "see also" links to docstrings #38606 (comment) I'd appreciate it.
• More generally if anyone wants to scan a few of these and object to any (or any patterns) that would also be great, even if you don't feel like reading all of them.

I would think that the newly documented ones should be in a separate PR than the cross-links. That might perhaps make it easier to get things merged rather than all in one shot.

I wonder what others have to say about that.

I don't mind moving them, although note that the two PRs will still be coupled, in the sense that links here won't work until their targets exist. The advantage of reviewing them in here is that you can easily search for the (proposed) links toward a given function. (They should all be gathered about here on the super-long "files changed" page.)

They are just things (like promote_typejoin) which seemed to deserve mention from somewhere (like promote_type) and cross-links without targets don't work. I have no opinions as to whether these functions are otherwise important enough to deserve documentation. If they don't, then the options are either to remove them entirely from "See also" to keep them hidden, or to mention them without making a hyperlink.

Makes sense.

Some comments of places to fix, but otherwise, lgtm