That is an interesting point.
The ability to construct a "state validator" (e.g. set of rules) and apply that validation to different objects, would be an interesting feature - for one, if you could compartmentalize validation rules in this way, you could apply certain validations both to a form and to a model object. You could also easily reuse a set of validations between different models, explicitly run the same validation set against multiple objects, etc.
You could also then supply reusable or standard validations - for example, a set of year/month/day properties could be validated using a reusable validation set.
Perhaps a grouping of validations could itself be just another validator - you could call this a "compound validator", "state validator" or "validator set".
I think adding more built-in context support increases learning curve, and you can continue extending those sort of features indefinitely and never be quite done.
I think if “compound validators” were classes, you could easily override it’s validate() method and introduce any kind of context-sensitivity you like, as code, with much greater flexibility than more “automatic” context sensitivity. I think you could probably even eliminate the notion of “scenario” from models, and have that feature in the “compound validators” instead - you’re not really configuring the model object, you’re configuring the validation process. Perhaps this is another indication that separation of the validation process would be a cleaner approach.