Thanks for sharing @julia! For what it's worth, I'll also share where I'm at right now.
I had something similar set up, with the difference that it was two packages' code that I wanted to expose through an API. First I placed a plumber file in each package's inst, and then had a small piece of code that programmatically defined a new plumber router, and mounted the two packages' apis in different paths.
As the api code grew a bit more complex, I got frustrated that it was less straightforward to test than regular package code. Also, as the two apis shared some of the logic of input processing, this resulted in duplicated code. That's why I ended up stripping the api code out of the two original packages, and made a new package solely for their joint api.
Now instead of defining it inside inst, I decided to go with regular package code. Only one function is exported (the one that runs the api), and the rest (endpoint handlers and aux functions) are not, but they are all straightforward to test with testthat. For me there were multiple (two for the business logic + one for the api) packages involved, but the testing benefit stands even if there is only one.
I'm not sure if it's possible to combine this with the "code-comment-definitions" approach, but at least for now I'm defining the apis programmatically. Swagger doesn't currently support that (easily), and @cole mentioned above that Connect's support is also a bit tricky / limited.
So I'm sure this approach is not for everyone, but I thought I'd share it here.