Several kinds of fields currently offer an 'allowed values' list where you can create either a hard-code list of possible value or some PHP code that will produce an allowed values list. The allowed values list is a field attribute that is shared between all instances of a field.
In our current D7 code, core will not allow changes to field attributes, only to instance attributes, mostly to prevent changes that would alter the data schema (like changing a SQL varchar field to a SQL text field), but 'allowed values' lists will need to be updated and changed, and those changes have no effect on the data schema.
Yves and I discussed this as we were bringing the code sprint work forward and decided to change 'allowed values' to an instance attribute instead and I made this change in the code. However I now see some problems this will create. The most important one is Views integration. In Views, we expose fields, not instances, and all the field settings and filter options are set at the field level. If instances have different allowed values lists, how would we create an exposed filter for that field to allow the end user to select a value to filter on? We would have to expose every instance of a field as a separate field. That would create a huge long list of Views fields, with fields like Node: Body (Page), Node: Body (Story), etc. And if you want to filter on the same value in different instances, you would have to create a separate exposed filter for each instance and set each of them to that value. That doesn't seem like a good idea.
So I think we have to go back to making it a field attribute, but one that can be altered, which means we need the core API to allow this.
During our discussion in the sprint we talked about this a bit and all agreed that the best solution would be to do something like pluggable allowed values list that could be shared not just among all the instances of a field but also between fields. I visualize a separate module for creating pluggable 'Allowed values' lists that exposes the available lists to our fields, then our core API would give fields a setting to identify which list to use.
This would be great for long and complicated allowed values lists that you don't want to re-create in every field. It could also reduce the need for using PHP code for those lists if the the 'Allowed values' stored only the name of a function that would return the list instead of raw PHP code.
Related to this has been the question of how to incorporate dependent or hierarchical allowed values lists where the value for one field is dependent on the selection in another. So some thought must be given to figuring out how that could be incorporated.
So the whole system of allowed values lists probably needs to be moved into a separate module that can provide some basic list functionality that could be extended by contrib modules, and a task would be to create a system to do something like this.
I'd like to get some discussion about this and hope that someone will want to step up and work on creating this.