tiny hold violations in Cyclone III, 1200 mV 0C

Interesting. Note that these are all registers feeding back on themselves. I believe their is a dedicated feedback path that is very fast for this, and the router(which is what adds delays to meet hold timing) can't break that path, which is why the options aren't helping.

That being said, the timing models are supposed to be setup where this doesn't cause a hold violation to begin with. Can you file an SR, as this should be fixed. (What device, out of curiosity).

For peace of mind, note that it is absolutely impossible to get a hold violation when the same register is the source and destination and the requirement is 0ns. Basically the data delay would have to physically be negative to get a hold violation. The reason timing analysis catches it is because a lot of uncertainties, jitter, etc. are built into the model and are valid for all transfers except this special case. I would ignore it until it gets fixed. You could also add:

set_clock_uncertainty -hold -0.233 -from <clock_name> -to <clock_name>

to the clock domain. This would artificially remove uncertainty and allow it to meet timing. I'm not a big fan of this though.