I agree with this. One way to keep changes small but still compose them into a coherent PR is to make each commit in the final PR independently meaningful, rather than what actually transpired during local development. TFA touches on this somewhat, contradicting the bit you quoted.
A trivial example would be adding the core logic and associated tests in the first commit, and all the remaining scaffolding and ceremony in subsequent commits. I find this technique especially useful when an otherwise additive change requires refactoring of existing code, since the things I expect will be reviewed in each and the expertise it takes are often very different.
I don't mind squashing the branch before merging after the PR has been approved. The individual commits are only meaningful in the context of the review, but the PR is the unit that I care about preserving in git history.
Counter-anecdotally, I reported two WebAuthn issues to Apple in separate instances and both were immediately fixed in the next patch version of iOS/Mac OS. In both cases first line support had little understanding of the issue but were very good at following process, trusting me, calling me back to keep me updated, and escalating to engineering as necessary.
There's a standard for this using NFC and UWB, Digital Car Key; BMW has support for either 2.0 (NFC) or 3.0 (UWB) across their entire range. The Hyundai Motor Company group (Hyundai/Kia/Genesis) is starting to add support as well. See [1] for exact models (look for the little key icon). Several other makes are members of the Car Connectivity Consortium that standardized this protocol so it's reasonable to expect wider compatibility in the near future. The protocol incorporates significant countermeasures against relay and replay attacks like some that are mentioned in other comments here.
Professor Daniel Abadi makes a similar point in his paper [1], where he improves on CAP with PACELC -- if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?. (From his blog here: [2]).
Klepmann makes an interesting critique [3], that neither is particularly useful because both imply that you must either pick linearizability or total availability. When in practice, there have been plenty of successful databases that present neither characteristic, and thus are neither CP nor AP.
A trivial example would be adding the core logic and associated tests in the first commit, and all the remaining scaffolding and ceremony in subsequent commits. I find this technique especially useful when an otherwise additive change requires refactoring of existing code, since the things I expect will be reviewed in each and the expertise it takes are often very different.
I don't mind squashing the branch before merging after the PR has been approved. The individual commits are only meaningful in the context of the review, but the PR is the unit that I care about preserving in git history.