I started checking out the new list validation features in 2010 recently and was glad that this was there. Typically if we needed to have something even as simple and ensuring a field has no duplicates, we either had to code up an event receiver that checked the value on submit and gave the message on another screen that looked like and error (totally not user-friendly). Another frequent case is some simple dependency between fields in the same list, eg. Start date <= End Date. One approach, as I mentioned was creating the event receiver, yet another, which I have seen some customers who are totally averse to customization carry out is enforce it as a procedural thing, which is less work for SharePoint devs (to ensure that people actually follow the rules, prehaps they check the number of mismatches and deduct it from their salary 🙂 )
Anyway coming back to 2010, there two ways in which we can carry out validations. One of this is on creation of the column. Actually when I created an EndDate column, I thought that I could add validation to ensure that it was greater than the start date.
So that ment that the column validation could be used only to compare with static and defined values eg. checking if it is greater than the current date etc. but not conditional based on other column values. The right way to do the check is via the list settings-> validation settings.
So why two different mechanisms for validation? I guess it could be so that columns can be used across multiple lists without dependencies on other columns required in the list.
Anyway a good feature to have to implement those basic requirements.