That claim is technically true. There's a lot of good stuff in here—partitioned locks, transaction recovery journals, a realistic expectation of WAN latency and

That claim is technically true. There's a lot of good stuff in here—partitioned locks, transaction recovery journals, a realistic expectation of WAN latency and reliability—but page 20 ("Local Autonomy") and page 37 ("NonStop Operation") give clues as to the differences from modern systems. Rather than build consensus-based high availability into the software, NonStop SQL relies on custom hardware and redundant networks that are designed to never fail. If they do fail, some portion of the data or some types of modifications become unavailable and the operator is expected to intervene and make choices about how to proceed. They give an example of being unable to run an ALTER TABLE statement because two datacenters that each own a shard of the table are disconnected—the statement can't be run at either datacenter during the partition. They give other examples where queries return partial results because a specific shard is down. This is potentially a correctness violation if it is not explicit, and it is definitely a loss of availability. Modern distributed systems are instead designed to maintain almost total levels of availability on constantly failing hardware, and heal themselves immediately and autonomously without losing correctness.