You wrote:
I can see the need for applications to easily and dynamically change from 12 to 14 rounds by simply updating a variable, possibly even a loadable value instead of changing the code forcing a recompile.
That's not my experience. The typical crypto application has some configuration or protocol handshake to select between aes128-ctr, aes256-ctr, salsa20, salsa20r12, etc. For each choice, it needs some logic to allocate the right context struct and call the right functions (struct nettle_cipher is an example of a minimalistic framework to collect that info).
Then, from the application's point of view, salsa20r12 is as different from salsa20 as it is from aes128-ctr, none can be be substituted for the other except via the algorithm selection procedures, and it really doesn't matter which of the different algorithms are unified below that algorithm-selection framework.
And the particular change from 12 to 14 might add significant complexity to an optimized implementations with 4-way unrolling, so flexibility isn't always as cheap as it looks.
I agree -- please just add 20 rounds ChaCha initially.
I am beginning to think that the introducing the 12 rounds Salsa20 was a really bad/harmful outcome of eSTREAM, as it leads to all these discussions around number of rounds to support, which slows adoption. The speed of 20 rounds Salsa20 and ChaCha is high. If speed is more important than security for someone, I've heard of this nice cipher called ROT13 that we could probably implement very efficiently.
/Simon