I think it's better to stick with the 3.5-days-in-the-future model that used for the existing HBD->HIVE conversion. This can be implemented using effectively the exact same code as the existing HBD->HIVE conversions, except at the end of the 3.5 day period, instead of dividing the quantity of HBD converted by the median price to calculate the quantity of HIVE delivered, multiply the quantity of HIVE converted by the median price to determine the amount of HBD delivered.
This prevents gaming after a big price change, as well as manipulation, since (setting aside manipulation) no one knows what the price is going to do over the next 3 days. The best estimate is simply the current price.
As proposed, there will be situations when the backward looking average higher than the current price. In fact, if it is >5% higher, then it will make sense to generate new HBD even when HBD is >$1.05. That's not desired.
The 3.5 day forward process like the converting HBD to HIVE, with the 5% spread, is pretty safe and sound IMO.
Also, I think the haircut threshold should be increased, but I guess that is a separate issue.
RE: Proposed hardfork change to stabilize Hive Dollar’s tracking of USD value