A signature may have multiple issuer subpackets. Supporting this may be useful to accelerate the adoption of v5-based certificates. Alice could convert her v4 certificate to a v5 certificate without retiring her v4 certificate, and her OpenPGP implementation could add both keyids to the signature. Then, when Bob tries to validate a signature from Alice, his implementation can still validate it even if his OpenPGP implementation only understands v4 certificates or only has the v4 variant. I've attached an example certificate, which gpg is unable to import.
$ gpg --import multiple-issuer-subpacket.pgp gpg: key 0xFBF21AC90EC54370: 4 signatures not checked due to missing keys gpg: key 0xFBF21AC90EC54370: new key but contains no user ID - skipped gpg: key 0xFBF21AC90EC54370: failed to re-lookup public key: No public key gpg: Total number processed: 1 gpg: w/o user IDs: 1 gpg: secret keys read: 1 $ gpg --list-packets multiple-issuer-subpacket.pgp # off=0 ctb=c5 tag=5 hlen=2 plen=88 new-ctb :secret key packet: version 4, algo 22, created 1618909780, expires 0 pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: [263 bits] skey[2]: [256 bits] checksum: 0f75 keyid: FBF21AC90EC54370 # off=90 ctb=c2 tag=2 hlen=3 plen=196 new-ctb :signature packet: algo 22, keyid 0123456789ABCDEF version 4, created 1618909780, md5len 0, sigclass 0x1f digest algo 10, begin of digest 1b db critical hashed subpkt 2 len 4 (sig created 2021-04-20) critical hashed subpkt 9 len 4 (key expires after 3y0d17h26m) hashed subpkt 11 len 2 (pref-sym-algos: 9 7) hashed subpkt 16 len 8 (issuer key ID 0123456789ABCDEF) hashed subpkt 16 len 8 (issuer key ID FBF21AC90EC54370) hashed subpkt 20 len 70 (notation: salt@notations.sequoia-pgp.org=[not human readable]) hashed subpkt 21 len 2 (pref-hash-algos: 10 8) critical hashed subpkt 27 len 1 (key flags: 01) hashed subpkt 30 len 1 (features: 01) data: [256 bits] data: [256 bits] ...