Isaac: thank you for your patch, a few comments...
1) the patch would definitley need to be updated to include some tests before this feature could be considered for inclusion in Solr
2) skimming the patch, i'm not convinced it behalves in the way you describe – in particula consider what would happen if (in your example usage) a document existed in the index which did not have any value in the "first_update_timestamp" field. from what i can tell the patch as written isn't actually doing anything to distinguish between the case of "this is the first time adding this document (so accept the field value)" and "this is the first time someone has tried to set this value" ... although perhaps i'm just missunderstanding what you're goal is?
3) i'm not sure that the verb "create" fits with the other existing verbs that are available for atomic updates ... it seems like what we really want is something more along the lines of "setIfEmpty" or "setOnCreate" (depending on the intended behavior as mentioned above in #2)
4) it's not clear to me from skimming the patch if this will work with multiple values, would definitely need to see a test case verifying that both values were added in a situation like...
<field name="foo" update="create">ABC</field>
<field name="foo" update="create">XYZ</field>
I would also like to point out that (unless i'm missunderstanding) for the initial use case that seems to have motivated this issue (ie: "timestamp when doc was first indexed", where the field must be single valued to make sense) i'm pretty sure this goal is already achievable w/o any code changes if:
- the clients always specify update="add" on this particular field
- FirstFieldValueUpdateProcessorFactory is configured on for this field after the DistributedUpdateProcessorFactory