How was FORKID used in Bitcoin Cash at the original fork point and in all upgrades since? References:

https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md

https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md

It looks to me like at the original fork point, Bitcoin-ABC added an extra value 0x40 called SIGHASH_FORKID that is xor'ed with the standard SIGHASH flags to produce a SIGHASH byte that is incompatible with Bitcoin Core. This provides replay protection for all transactions that are signed with ECDSA pubkeys.

Questions:

Is the FORKID updated with each "protocol upgrade" for example the recent "Magnetic Anomaly" upgrade? If not, why not?

It looks like the May 2019 upgrade will change the FORKID to 0xFF0001 but the spec mentions "Wallets that follow the upgrade should not have to change anything." -- how is that possible?

Did Bitcoin-SV change its FORKID for its recent hard fork away from Bitcoin-ABC? Is there any replay protection at all between those two chains?
The purpose for "after certain time, set FORKID to 0xSMTHNG" is to keep the old chain alive but separate, in case of a bug in hard fork. After a Bitcoin Cash hardfork, let's say November 2018, if you're using an incompatible client, a client that complies with May 2018, it'll make transactions with a FORKID that starts with 0xFF00, and those transactions will be invalid in the new chain. Wallets shouldn't enforce this rule, as it is assumed that they're not nodes and they are not interested in (some of) the new consensus rules, which are usually little changes, like new opcodes.

Trivia: Bitcoin SV was derived from Bitcoin ABC complying with May 2018. If they didn't commit this, there would be replay protection.