This bug is a replacement of bug #22735(24.3; org-set-effort *without* numeric prefix - still forces me to use nth allowed). After more experimentation, I got a better understanding of the functionality and now consider that bug 22735 to be invalid as written. I now think it's a more fundamental issue of not handling an Effort_ALL with more than 10 entries. The problems manifest in both interactive org-set-effort and in column view when editing values via direct index selection.
1) interactive org-set-effort
1) can not enter an index > 10
2) method of entering a raw value is arcane and unvalidated
- by prefixing the entered value by '-', you can enter one of the Effort_ALL string directly
- e.g. Effort_ALL 0 1h 2h 4h 1d 2d 3d 4d 1w 2w 3w 4w
- 'C-c C-x e -4w RET' sets Effort to '4w'
- however, a value of '-foobar' sets Effort to 'foobar'
3) Note: org-set-effort with numerical prefix works properly for indices > 10
2) column view - editing values
1) 1-9,0 - can not enter an index > 10
- lower priority than 1.1 above since column view edit 'e' allows direct entry of Effort_ALL strings (with validation)
2) Note: S-left/right, n, p work properly for indices > 10
- interactive org-set-effort and column view direct index selection
- input multiple characters followed by RET
- if input is a valid index, use the corresponding value from Effort_ALL
- else if input is a valid Effort_ALL value, use it
- else beep and display [No Match] (like column view edit when an invalid value is entered)