1. Correct, my point was to emphasise that the implementation is the same. I've just updated it, thanks!
2. We often make the assumption that pages can be flushed to disk atomically, which is not very far from true on modern disks. Because the only update that really needs to be atomic is for these tables, they're all stored on one page. Since these pointers are all 64 bits in size (since 4k = 2^12, 12 bits in each of these are 0s), after a header of a few bytes, that leaves about 500 positions. The first few are probably more often atomic than the last ones, especially on very old disks.
3. It's still very important, but less so, because the Pijul repositories are much lighter on disk. Copying 1Mb is fast, but copying 100Mb is 100 times slower. I still like this feature, because (1) it costs almost nothing extra and (2) I really like the implementation.
So you're assuming native 4KiB sector support (which requires both modern disks and operating systems)? Traditional 512 byte sectors only allow for 61 tables to be updated atomically.
What happens when you exceed the limit? Does it silently become non-atomic?
Also, I find it a bit strange you're talking about pages, not (disk) sectors.
Well, I must admit that users currently need to know a little bit about how things work in order to use it, it isn't completely foolproof.
As an example, the type of channels/branches in Pijul contains things equivalent to `BTreeMap<String, (BTreeMap<Vertex, Vec<Edge>>, BTreeMap<u64, Change>)>`, and failing to update the pointers can result in corruption. Of course one can provide a safe interface on top of that (which I do in Pijul), but that depends on the types, so it isn't done yet (macros to derive safe implementations would be a really cool project btw).
Edit: to answer your question more specifically, small sectors might make it silently non-atomic, but there are workarounds (for example by using an extra level of indirection).
There is no modern hardware for sale that actually has 512-byte sectors, and hasn't been for many years now. (More than a decade, I think...)
If you don't have 4kiB sector support, then the hardware is typically emulating 512B sectors on top of it's native 4kiB sectors. If the partitions are properly aligned, this still gives the same atomicity functionality.
2. Where does the 500 tables thing come from?
3. I don't fully understand why the importance of copy-on-write forks is much less important now