There's a typo in the language-agnostic search: /int128|int128 is missing an underscore (it's there in the actual search, just not the link text in the paper).

"QoI (Qualify of Implementation)" is another typo.

Better support for bitcoin is an anti-feature IMHO.

There are a number of assumptions in the paper that seen to exclude 32-bit and smaller systems. Existing implementations do not support 128-bit integers on all platforms (and MSVC doesn't support them at all). Similarly for std::float128_t, that's an optional type and not universally supported. Adding a mandatory int_least128_t doesn't seem trivial at all. Unless I missed it, this isn't mentioned anywhere. This is a major problem for the proposal. If the new types were optional so not required on 16-bit and 32-bit platforms the proposal would be much less difficult.

std::timespec is only a 128-bit type when std::time_t is 64-bit, which is not universal (although the 2038 epochalypse is approaching so that's starting to change for some platforms).

"Also, if there exists at least one standard library which implements these features, it is assumed that they can be adapted into other libraries with relative ease."

As the maintainer of such a library: we already support __int128 on some platforms, but that doesn't mean we can support it on all platforms.

Your discussion of iota_view fails to mention that a standard int128_t type would be a valid template argument for iota_view, and so would require a new integer-like class type like _Signed129 (or more). Libstdc++ already has such a type because we already allow iota_view using 128-bit integers, so we have a difference type that's even wider.

If your intention is that the existing random number generators and distributions could be instantiated with uint128_t then that would require wording changes to [rand.req.genl]. And implementations would need to do 256-bit arithmetic, e.g. for the product of two 128-bit values in the transition function of std::linear_congruential_engine<uint128_t, ...>. That might not require wording changes to the standard but the additional implementation effort is worth calling out.