I understand that you have a good idea of the tradeoffs here. What I am trying to tell you is that the average developer does not have a good understanding of the performance issues caused by ids that are not k-sortable and will simply assume this library solves them. Which it does, but not in the configuration suggested at the top of the README, which is the one those users will assume is the recommended default.
However I see you actually removed those performance claims from the README yesterday so I suppose that’s a fair enough compromise!
I am aware there are use-cases which can get by with 4-byte ids (or less!), but in the past this has caused substantial problems. Libraries like Rails/ActiveRecord defaulted to 4-byte ids and many did not anticipate how many rows they would end up having, leading to difficult migrations.
It’s entirely possible to design a database which makes it easy to migrate this BTW, it’s just that Postgres specifically does not handle it well and it has caused a huge amount of trouble in the past. For most use-cases 64 bits is fine. If you know what you’re doing then of course you can exercise good judgement.
This is just a manner of speaking. It does not refer to you literally. English is a ridiculous language.