According to that bug report it says the issue was fixed in Safari 13 and also iOS 13 like you said, but caniuse says there is still an issue.. I'm on 12 right now and can't update to check atm.
https://caniuse.com/#feat=same-site-cookie-attribute
Yep, that's the issue. I think I see the confusion now (I stand by my original comment).
SameSite=Lax was never an invalid value, so it was never mishandled by browsers (very old browsers gracefully degrade to treating it like None, which is as good as possible). In the original spec there was Lax, Strict, and unspecified (i.e. the Set-Cookie header didn't have a SameSite attribute, the default behaviour) but, critically, no None.
Browsers developed around that time that treated unexpected values as equivalent to unspecified/what we now call None (e.g. Firefox) turned out to have picked a more forwards-compatible approach. Browsers like Safari and Chrome took stricter action for unexpected values (the idea here is a vague "secure by default" feeling) but it's awkward now that the default is changing from what is (now) called None, to Lax.
In that issue, consider the title "Cookies with SameSite=None or SameSite=invalid treated as Strict" redundant: None was an invalid value according to Safari at that time, which wasn't wrong.
SameSite=Lax is 100% safe to set (assuming your site is ready for that). You only need to browser sniff if you're considering setting SameSite=None.
Interesting theory. I don't think it's true, though. The original spec mandated case-insensitive comparisons and it looks like WebKit has always been doing that to me.
SameSite=Lax was never an invalid value, so it was never mishandled by browsers (very old browsers gracefully degrade to treating it like None, which is as good as possible). In the original spec there was Lax, Strict, and unspecified (i.e. the Set-Cookie header didn't have a SameSite attribute, the default behaviour) but, critically, no None.
Browsers developed around that time that treated unexpected values as equivalent to unspecified/what we now call None (e.g. Firefox) turned out to have picked a more forwards-compatible approach. Browsers like Safari and Chrome took stricter action for unexpected values (the idea here is a vague "secure by default" feeling) but it's awkward now that the default is changing from what is (now) called None, to Lax.
In that issue, consider the title "Cookies with SameSite=None or SameSite=invalid treated as Strict" redundant: None was an invalid value according to Safari at that time, which wasn't wrong.
SameSite=Lax is 100% safe to set (assuming your site is ready for that). You only need to browser sniff if you're considering setting SameSite=None.