If you add this feature, I suggest you clearly document its purpose. Writing a short comment in the segments file can be useful when utmost performance is needed (e.g., like when you just want to check if you want to reopen() or not), but my guess is that for most other scenarios, there's an alternative in the existing Lucene.
I.e., one possible way to achieve almost the same goal but without changing anything in the code is to put a special document in the index - e.g., imagine you put a document with some unique searchable field/term combination (just to find this document), and a stored field with your "userdata". Before doing the next commit(), just update (i.e., delete and add) this document to a new value, and commit().
This method is not as super-quick as the one you proposed, but I think that for most uses it is quick enough, and more versatile. For example, what happens with the proposed feature if the code that needs to write this "user data" is in a library, which cannot control exactly the commit() times? And what happen if several different libraries or code modules want to write their own different "commit user data"? With the simple alternative method I mentioned you have: 1. several "commit user data"s can exist (by using different field/term to find them), 2. a library can put the commit user data to the index and have it take effect on the next commit (rather than needing to specify it in the commit() call). 3. an extra commit() call does not delete the previously set data (I'm not sure what you intend to do in this case in your suggestion).
I guess that it wouldn't hurt to add the feature that you propose - I just hope that people don't start using it for things that established Lucene mechanisms (like documents) would have been better.