Ok, sorry. Let me explain that a little better.
We have 1 repository, which holds
/Manuals (What antora would call a "component")
/Manuals/Extrusion (What antora would call a "module")
/Automation (we would move that into another repository, actually, its another team...)
/Commons/Settings.adoc (what antora would call a "partial")
All of the manuals and automation docs (what antora would call "pages") include the //commons/settings.adoc to control their appearance and behaviour when we transfer them to pdf's using asciidoctor-pdf. Also we refer to the iconsdir alike.
Now, how do we get that to antor aso we can use the repository in BOTH ways, that is as source for pdf's and also as a website. Maybe I can't.
but I think it would be only a moderate amount of work to (1) have antora export some aspects of the content catalog and (2) provide an asciidoctor extension or plugin to interpret Antora style reference correctly.
exactly. And when parsing AsciiDoc, Antora works exclusively via Asciidoctor extensions, so all of it can be replicated outside of Antora (provided you have all the metadata you need).
I'm not sure how easy it is to add extensions/plugins to the asciidoctor browser plugins
it's not hard. there is a field in the configuration page for them
You dont want to run it through antora to find out there is a typo in an include:: or image:: or a blank which kills the table or whatever.
I think you do, because otherwise you won't be totally sure there isn't an error. but that's just my (strongly held) opinion.
I'm wondering if some of the problems are that plain asciidoctor and Antora syntax for reference targets is different.
they are different, but what Antora does is not non-standard. it uses the standard extension mechanism in Asciidoctor to enhance the syntax (to make it more context aware). we are very careful not to modify AsciiDoc, but rather to channel everything through extensions.