Rename the Options module (which contains the former List module as well)

Option controls ?
http://www.w3.org/TR/html401/interact/forms.html#control-name

My Best -> Worst order:
1. Options Values / Option controls
2. Option List
..
..
(Worst: non-listed candidates)

Why not something like field_options or field_allowed_values or allowed_values_field or something? Neither "Options" nor "Allowed Values" by themselves tell me WTF they're for. :)

Edit 2: No, not what I said in edit 1.

#2 Option Controls sounds good it makes sense to me.

What about allowed field values / allowed field controls ?

But given the current options in order of preference I would go for.

1. Option Controls / Options Values
2. Allowed Values
3. Options list

Allowed Values Controls or Option Controls imply the control widget is the primary functionality, when in fact the primary functionality of the new module that has both the field and the widget is the API for creating and displaying a list of values. The widget is secondary, IMO.

Another possibility, 'Allowed Values List', which is slightly more descriptive than just 'Allowed Values'.

We're talking about a name for the module that contains the both the allowed value lists field, and the option widgets, right? [YES, tim just confirmed that in IRC]

In any case, I vote against "Listing" for sure, since I never understood the "List" name for the old module in the first place.

My preference for a name for the combined module would be for one of the following:

Option Values
Allowed Values
Option Lists

I will also update the issue summary to clarify we are looking for a name for the combined module.

I'm starting to lean toward something like 'Option list' (singular, it's one list with a bunch of values). It's fairly descriptive and it also hints that it contains both the 'Options' and the 'List' module functionality.

My proposal in #1592632-82: Merge List field types into Options module was:

What are allowed values?

An allowed value is a value of a selected list of valid values; a selection.

Alternatives for: "selection"

Main Entry:     assortment
Part of Speech: noun
Definition:     variety
Synonyms:       array, choice, collection, combination, combo, diversity, garbage, group, hodgepodge, jumble, kind, medley, miscellany, mishmash, mixed bag, mixture, mélange, potpourri, selection , sort 

Apparently, "Choice" also applies to option widgets a.k.a. "Options". — Why is that plural to begin with? ;)

I'd assume that even end-users can make sense of what a "Choice (number)" field is in the UI. Happy end-users++ ? :)

RE #9 - I am not in favor of having the module name have "select*" in it, because it sounds too much like it's specifically for HTML "select" input fields, and this also applies to radios and checkboxes.

So... Just about everyone who has commented here has included "Option List" (or something close to that) as one of their top picks. I would like to propose that as the name. Thoughts?

@jhodgdon: The proposal in #9 is "choice".

RE #11 - you mean you want to propose "Choice" as the name of the module, or combine it with another word? To me "Choice" alone doesn't tell me much.

Note that once this module is re-named, both the field module and the widget module names need to be updated in the field_config and field_config_instance tables, as noted in #1697408: Update module name in field/instance config for List fields

Out of all the proposed alternatives, Choice strikes me as the only viable change, mostly because every other module, except Field UI, is one word.

Are there any other possible changes on the horizon for how fields get user entered data, or to how Options module could be used more widely?

One important development which may inform this issue is that #1801304: Add Entity reference field recently added support for using Views to control its options list.

Yes, Choice still makes the most sense to me. I'd love if someone could take this on.

(I started to do this, but my local branch is from months ago and merging HEAD results in conflicts only.)

This script should do the trick. I would've supplied a patch too, but I had trouble adding the new files.

cd core/modules/field/modules
mv options choice
cd choice
find ./ -name '*' -exec rename 's/options/choice/g' {} \;
find ./ -name '*' -exec rename 's/Options/Choice/g' {} \;
find . -type f | xargs sed -i 's/options/choice/g'
find . -type f | xargs sed -i 's/Options/Choice/g'

I am still not convinced about Choice as being the best name for this module, but I guess it is not any worse than any of the other field modules, like Text and Number for instance, and it's kind of consistent with those kind of lame (IMO) names....

But I'm just wondering why anyone thinks that the module name needs to be one word? Do we have a standard for that? I don't think so. Why couldn't we choose a longer name (I'm talking about the user-facing name that you'd see on the Modules page) that makes more sense?

Moving to options.module

Clarify we are naming the combined list/option module

What about simply deprecating the module in favour of Taxonomy? Are there any reasons to keep it around when Taxonomy always seems to be the better choice?

It's not always the better choice, one advantage is that a list field is far more performant than a taxonomy reference because it doesn't require a separate entity/entities to be loaded when editing/viewing the entity. That's considerable overhead.

If you have a fixed, limited set of options, then using a list field is fine, it can also be extended later, the only thing that's not allowed is removing used options.

That said, this might be a won't fix now because doing it now would be a lot of pain for little gain, looks like nobody found it important enough to complain about this in the last 5 years.

The only thing that might be worth it is just moving the stuff into Drupal\Core\Field/text.module/views.module and not requiring a separate module for it. There really isn't a lot of code left.

Except few functions in options.module everything could be moved to Drupal\Core\Field and other modules

I agree with @Berdir that list/options module might be more performant than taxonomy reference since Drupal doesn't have to load terms from DB, as long as it's not already in memcache. But as a service provider, I almost always prefer to use taxonomy terms than list/options. The problem is that once an option is used, it can not be deleted. If the client still wants to delete an option, we first have to delete it from wherever it has been used. That's a major headache that we want to avoid down the line.

See my proposal at #3022862: Consider deprecating the Options module in favour of Taxonomy.