But nothing about the API is specific to pagination. This library essentially is just two other API calls: marshal and seal. It can do this operation on any marshal-able type. By using this library, you lose control over marshaling, which seems like a high cost to pay for this very simple and basic functionality.
You're conflating how it works internally with whether it's useful. You've critiqued is internal details but you haven't engaged with the premise of why you might want to use it.
A coin is just a metal disk. A dollar bill is just a piece of paper. Neither of them do anything. After adopting them, you lose control of how your cash is represented. And yet we find them useful.
A simple implementation is a virtue, not an albatross.
No, I'm sorry, you are not correct. I am not conflating internal implementation with whether or not it is useful. Rather, I am evaluating the opportunity cost, i.e. comparing this library to the "next best thing."
For this library, the next best thing would be to make two simple API calls instead of one simple API call. As a cost, this is very low. However, the "next best thing" also has a number of desirable properties compared to this library: better support for custom serialization and a lower attack surface for supply-chain attacks. When you look at the costs vs. the benefits of this library, the utility is negative.
Using your example of currency: a paper bill is not just a piece of paper. It's a piece of paper coupled with the vast machinations of a nation state that can enforce its currency via its monopoly on violence. You can't get all the benefits of a $100 bill just by having a green piece of paper.
