---
feature_story: FS_76_29_13_28
feature_title: command_arg consumption priority
feature_status: TEST
---

There are two orders which can prioritize `command_arg` consumption:
*   user input: the order in which args are specified on the command line
*   user config: the order in which `arg_name`-s are listed in FS_31_70_49_15 `search_control`

This is different from interrogation - when there is no consume-able `command_arg` anymore
and user is given suggestion to select from.
User interrogation is according to "user config" (FS_31_70_49_15 `search_control`) priority.

For the purpose of `command_arg` consumption prioritization (at the moment):
*   user input is used - `arg_value`-s are tried to be consumed in the order they are specified
*   user config is ignored - which `arg_name` gets filled next is random
    (based on dynamic order inside `remaining_prop_name_to_prop_value`)

The feature determines behavior for cases like:
*   TD_76_09_29_31 overlapped `prop_value`-s from diff `prop_name`-s
*   TD_99_99_88_75 mutually exclusive `prop_name`-s from diff `prop_value`-s

See also:
*   FS_44_36_84_88 consume args one by one

TODO: FS_76_29_13_28 Why not define the order based on FS_31_70_49_15 `search_control`
      (instead of whatever internal order `remaining_prop_name_to_prop_value` has)?
      It could already be the case that `remaining_prop_name_to_prop_value` are ordered as `search_control`.
      Why not make it explicit?
