I am not aware of any outstanding SHA-1 issues that would require a change in the current RFC4880 OpenPGP standard. There was an obscure attack that involved generating two keypairs with colliding SHA-1 signatures and getting a third party to sign one of them but you can just use a different hash (say SHA256). The SHA-1 used in the MDC portion of the authenticated encryption mode doesn't and is very unlikely to ever represent any security weakness (the hash used there doesn't require any particular cryptographic properties). SHA-1 is used for the key fingerprint, but the use of a hash with collision resistance is not required in general for key fingerprints. An attacker could in theory create two different keys with the same fingerprint, but then they would just own two keys that would be hard for to distinguish from one another. You don't sign the fingerprints, you sign the actual public key. In general, it would be a bad idea to specify that the hash used for a key fingerprint required collision resistance as that would mean that the fingerprint would have to be something like an unusable 256 bits long to prevent birthday attacks.
There are higher level implementations that use the dates on signatures to straight out reject sha1 material, but that gives only a limited protection.
Yep. We've got it working with OpenPGP Card devices (Yubikeys, Nitorkeys, etc.). The signing part was actually pretty easy and the decryption required a bit more work but the maintainer was super responsive (https://github.com/rpgp/rpgp/pull/315).
How does it interface with the cards? IIRC the rust pcsc library used by Sequoia needed C libraries. I've been doing some NFC stuff too and was looking for a pure-rust solution if there was one.