Which key(s) is it signed with? What is the hash of the corresponding unsigned artifact?
Signature verification tools should have some option which prints these things in a machine-readable format.
I did some work on reproducibility of Android apps and system images with Nix, and while defining a build step which can automatically establish these relationships sounds a bit goofy, it can make the issues with underspecified edge cases visible by defining verification more strictly. I did not do this to look for those edge cases though.
I am still working on that type of stuff now, but on more fundamental issues of trust we could start addressing with systems like Nix.
i still believe "pgp is too complex" was the most successful cia counter action after they lost the crypto wars to the people.
solving via nix only works within the flawed assumptions that end users either fully trust google or fdroid and are incapable of anything else.
Signature verification tools on the command line do not surface enough information to make it easy for their users keep track of what the unsigned input was.
I don't think their users are "end users" though. I am concerned about having better UX and making it more accessible to check these things, but for very advanced users, developers and security professionals. I think surfacing this to end users might come a few steps further down that road, but I am not thinking about that yet. I guess that's why you're talking about trust in google or f-droid, because you're thinking about end users already.
For now at least professionals should have an easy time keeping track of what the corresponding unsigned artifact to a signed artifact is, and we are far away from that right now. You have to write code for that, or inspect the binary formats of those signed and unsigned artifacts. That's not good enough. If that code is part of the tool in the first place, that automatically means that the semantics of the signature are much more well defined.