There is no such thing as a fee-requiring-tx, the default miner won't mine for some transactions, but the warning message should not imply that it is the protocol that prevents very small free transactions but merely the default implementation of the miner.
Ok, agree. I think conventions for what and where fees are expected are a separate issue. But as long as no different set of rules is designed, and the client enforces those rules in the transactions it creates, no transactions that include a fee should be created beyond the user's (or JSON-RPC client's) control. Gavin's proposal does that nicely.
although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.
Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units.
Ok, agree as well. But again, maybe introducing a new version of the protocol may or may not be worth the effort.
Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.
That comes close to my "Idea 1", and brings us back to the issue of whether it is the responsibility of the JSON server to provide encoding/formatting of numeric amounts for human readability (and humans with varying tastes).