A coin selection that returns None tells you nothing. Every support ticket after that starts with a guess.
I hit this building custodial BTC wallets. A withdrawal fails, and someone has to work out which of three unrelated situations they are actually in.
The user genuinely does not have the balance.
The balance exists but sits in dust that costs more to spend than it is worth.
The amount is fine, but the fee at the current rate exceeds the value being sent.
Same None. Three different responses: top up, consolidate, or wait and resize the transfer.
So in utxo-select I made the failure a first-class return value. Insufficient funds, dust-only inputs, and fee exceeding value are distinct outcomes carrying the numbers behind them, not a null. The caller decides what to surface to the user; the library refuses to flatten the distinction in the first place.
The broader lesson from years of payments work is that the empty result is where your operators live. Success paths get designed with care and failure paths get a null, and then the difference between user error and a fragmented wallet has to be reconstructed by hand during an incident.
The code is at github.com/polycratia/utxo-select if you want to see how the outcomes are modelled. I wrote up more of the reasoning behind decisions like this one here: https://polycratia.com/c/e36515ca
Where do you draw the line between a typed failure and a plain null in library code you maintain?