
TODO: TODO_66_66_75_78: Split `arg` to `prop` concepts:
*   `arg` is about command line input
*   `prop` is about search, envelopes, data backend

BUT: Make realize that and emphasis that (`prop_name`, `prop_value`) is discussed in almost all cases!!!
     Apparently, even when we specify (`arg_name`, `arg_value`), we actually mean (`prop_name`, `prop_value`).
     It is a mere technical implementation that we treat input as (`arg_name`, `arg_value`) because it still
     has to be mapped and consumed.
     So all exiting `arg_name`, `arg_value`, `prop_name`, `prop_value` should be reviewed if used correctly.

We map `arg` from command line to `prop` for search.

Split:
*   "arg" group of concepts (`arg_value`, `arg_name`)
*   "prop" group of concepts (`prop_value`, `prop_name`)

Note: there seems to be no way to tell `prop_name` until `arg_value` is matched as some of `prop_value`-s.

In fact, all `command_line`-level concept (like `arg_name`, `token_bucket`, etc.) have to be clearly distinguished
from data backend concepts (like `collection_name` and `prop_name`-s) even though they are closely related via mapping.

Issue:
*   `command_arg`-s are mapped to `data_envelope` props and almost identical
*   BUT: they are not naturally/intuitively inter-change-able as `data_envelope` properties are hardly `command_line` arguments.
*   Maybe write doc on bounded contexts? Add dictionaries (ubiquitous language) per bash, client, server, data backend?

See also:
*   FS_62_25_92_06 manipulating `assigned_context`
*   TODO: TODO_55_51_89_92: review and update `args_context`
