Thanks for the further comments folks. With regards to the underlying representation being a u64, I guess it’ll save a lot of further time if I agree that we should adopt this approach. So I’ll agree to that now 
Well, I believe my argument that it makes the code clearer still stands, but I understand that’s a personal opinion. His arguments didn’t (don’t) make a more compelling case to me, but I don’t want to draw out the discussion on what I consider to be an implementation detail.
I really hope this isn’t seen as me wanting to win an argument btw! I kept the discussion going before because I couldn’t understand how my point of view was so controvertial… I wanted to understand. I’m reasonably convinced now that there’s no lack of understanding on either side - it’s just a difference of opinions.
Agreed. I expect once we reach a conclusion on the various points in this forum topic, the RFC will be updated to relect the consensus. So for this particular one, I expect the Coin struct to be updated to hold a single u64 as my current example code does
I feel the bigger issue needing a conclusion is the level of divisibility, and after reading the Bitcoin discussion linked by @mav, I’m now favouring divisibility down to micro-coin. Again, this is just my own personal opinion. I do try to be careful to say “I” when it’s my own opinion and “we” when I’m talking on behalf of the company or backend team, etc. I’m sure I slip up now and then, but I try to remember
Thanks again for the constructive feedback and support, all!