I was finally able to successfully notarize my plugin bundle in such a way that the main application can load the plugin. This is not pretty.
Our plugins are bundles with the .xop extension. I renamed the bundle to have the .app extension, and then created a .dmg container to hold the bundle. I then uploaded the .dmg to the notary service. The notary service accepted and notarized the .dmg. When I look at the log for the notarization process, there are two entries in the "ticketContents" array, one for the outer .dmg file itself and one for the .app file. The actual executable in the bundle, located in Contents/MacOS, is not included in the ticketContents list. However, a few minutes after the notarization succeeded, I was able to run my application on a separate machine and the bundle, still with the original .xop extension, was successfully loaded by my application.
I have not yet tested whether stapling a ticket to my .xop bundle works, or if I can staple the ticket to the temporarily named .app bundle and then rename give it the .xop extension.
It is also not clear why I need to go to the trouble to notarize the plugin in the first place since my main application includes the com.apple.security.cs.disable-library-validation entitlement.
I have also not tested whether a plugin signed/notarized by a different developer certificate than the main application will load.
For the record, I am doing the code signing and notarization on Mojave, and testing the application on 10.15 beta 3. Also, the .xop bundle itself does NOT use hardened runtime. Based on the documentation for hardened runtime, it is the application that controls the hardened runtime entitlements, not the plugin. But I don't know if that documentation is actually correct.