The dynamics of the script is simple, no explanations needed, look for yourselves:
I do not think that this can be a useful issue description because there may be
secondary aspect to consider for when requesting changes, including backwards
compatibility after a given change/suggestion. So even if there were a problem in
regards to the behaviour, it would be better to include these considerations in the
issue tracker, even if you think that any behaviour is flawed or not optimal.
If you work with .any? .select and .reject, I personally found it better to split
up the tasks, finish working on the dataset, and then do a separate reporting. Right
now you combine both in one go, which can lead to the confusion you described.