As a user I would like to allow the use of a queue for field indexing so that installing the module doesn't take forever.

Ok this has become higher priority because of the following:

in #2707123: entity_load to load all entities at once causing module to be unusable on sites with large amount of entities of type being loaded, rossb89 did a pretty damn good job making the module not be a memory hog by not loading entities all at once. However, we have a similar issue now with field items when there are a crap ton of them across any particular field. You can see that here

This has been noted in a really late comment by giuvax over in #1995022-10: Error while rebuilding views natural sort index - AJAX error; Column not found - Unknown column 'eid' in 'where clause', stating:

[21-Dec-2016 17:39:12 Europe/Rome] PHP Fatal error:  Allowed memory size of
268435456 bytes exhausted (tried to allocate 72 bytes) in
/home/qcfilmtv/public_html/redazione/sites/all/modules/views_natural_sort/views_natural_sort_text_field.module
on line 97

We should provide a queue module developers can add items to instead expecting them to return all their entries back via an array. Then we need to upgrade the batch processes to run the queue instead of expecting all the information up front. We probably should look to Queue UI for guidance on this as the whole purpose of that module is to run a queue in a batch process...

Ok. So looks like I've got a fix that needs testing in 7.x-2.x-dev. Give it a shot and see if it solves the needs of those who run out of memory. Technically you can use drush here as well by doing drush queue-run views_natural_sort_index_queue. This is because I implemented this as a cron queue (that doesn't run on cron btw).