Most Maven Deployers use collectDeployables() method with no parameters, and their workflow is thus:

• Collect all deployables. If there are .asc deployables, e.g. signatures, already present in staging repository, these will be collected.
• If sign is enabled, it will try to sign all non-signature deployables which are newer than existing signature, if it is present. This means they will not overwrite existing signatures and will not do any signing work if signatures are already present for all files.

However, Nexus3 deployer calls collectDeployables(deployer.isSign(), false).

• This means if sign is disabled, signatures will be neither collected nor deployed.
• If sign is enabled it will sign all artifacts again and require key chain to be present. This is serious divergence from normal behavior.

But in fact, it gets worse. Deployable always uses last portion of file name after the dot as extension, e.g. asc. But for Nexus 3 in its read and write APIs, extension for such files should be "jar.asc" or "pom.asc". Even for a simplest Java deliverable, Nexus3 deployer will try to submit two positions of signature with extension "asc" and artifactId/groupId/version all identical. Nexus3 has no way to understand which specific file (pom or jar) this signature is for, so it will reject the submission. So I actually doubt that Nexus3 deployer is able to submit any signed artifacts at all in the real world.

I am using 1.19.0.