Hi,
No, as far as I know, hosts are not required, via the that Audio Unit API, to update the info for a parameter after those parameters have been set by the plug-in during construction/initialization and the AUBase::GetParameterList() and GetParameterInfo() combo has been called.
In fact, I think most hosts rely on the fact that the type, min, and max values of a parameter do not change during the lifetime of the plug-in. For example, in an automation lane, it is probably helpful for hosts to just map min and max parameter boundaries to the Y coordinates of the track/lane UI. Simplifying the range is probably also helpful when hosts load plug-in automation from a saved file.
In other words, this behavior may be just a healthy design compromise to give AU developers flexible-enough parameters, while reducing the required implementation overhead for hosts.
In your case, I would consider the following options:
1. Add a new boolean/toggle parameter separate from your max-of-a-1000 parameter. Then, just manually control, or ignore, its value depending on the state of your audio unit. Also, consider if this toggle is a three way toggle or just a two way toggle. If it is two-way, then just use the boolean field (returning kAudioUnitParameterUnit_Boolean in AUBase::GetParameterInfo().)
2. Leave the max of your max-of-a-1000 parameter at its true absolute max value for the lifetime of the AU. Then adjust the value manually as the state of your audio unit changes, possibly forcing a value lower than the absolute max. I have done this myself with discrete parameters where I can control the value of the parameter in the host UI, and force a logically consistent value, regardless of what the user tries to do.
--Christian