I would recommend you to think about more immediate issue - year 2106 problem. But this is probably irrelevant because all current cryptocurrencies will be destroyed by quantum computers much sooner.
Things like the 2106 problem are easily addressed with very trivial changes that don't even need to be changed at the protocol level, for example simply allowing the overflow. These things are also not specific to moto, so we can expect some solid patch will come along from upstream long before it is an issue, so we probably shouldn't even need to expend any effort on thinking about it.
Things that are specific to our coin, like "so just how does the network's subsidy behave in 200+ years, assuming things like crypto primitive changes to handle quantum etc..." are still valid questions regardless of anyone's opinion on if a total cap is best or not. When it comes down to issues like "this bug means X for this coin network specifically, on some future date" the existence of that bug factors into an assessment of the coin. As I've illustrated already, some very silly conclusions like "sell all at 1 SAT now!" can be erroneously drawn from some of this, but some valid conclusions can be drawn as well. Should moto happen to persist, I wouldn't want to be the guy sitting here a couple 1000s years from now cursing my ancestors for making some silly rule that to send 84million+ coins one has to also spend 84million+ coins. As an investor today, I might wonder how others would perceive the developer's "shrugging off" such oversights in the implementation (which are usually "standard bullet point items" for an alt. Most any ANN post on this board will have a bullet listing total subsidy details, and you really want what is announced and advertised there to be truth!) and might wonder what else they've overlooked in their fork from ltc.
What is most troublesome right now, though, is that both camps in the "should it be capped" debate would be dissatisfied with the current state. We have an infinite subsidy, but an effective cap at an 84million coin denomination, at which it becomes impractical to spend. Pragmatically, the network fails to meet either proposition. (EDIT: and my real concern is in what other still unknown ways it might fail to meet either. IMO it really needs to pick one or the other and implement it as such, completely and correctly, end to end.)
In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon. Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.
Can you be more specific, what are "these rpc calls"? I'm not an expert in all of the bitcoin rpc calls, which call depends on total supply? What "these things" except total supply are you talking about?
My apologies, I was confused. I guess there aren't any of these work details exposed in the stock rpc set. From a quick skim over some things, it looks like the only thing directly affected in the reference wallet right now would be the block/tx handling.
(EDIT: But on a related note, we might want to look very closely at GetBlockWork before we do any check-pointing...)