cbbackupmgr restore seems occasionally blind on keys that cbbackupmgr examine correctly retrieves

Restoration via cbbackupmgr restore seems to occasionally (but dramatically) fail without any notice nor log on keys that cbbackupmgr examine proves instead to exist, e.g.:

1. the key "example:00C48C10-B6F4-4750-BDEA-642F1A96A3AB" is immediately found by cbbackupmgr examine{{ __ }}within a __ full backup __ (say "2022-11-09T22_40_02.19803404Z", the oldest one, on the ground of further 27 incremental ones);
2. the same key is not found (nor restored) by cbbackupmgr restore _  between the same _full backup and a later incremental one

1. {{cbbackupmgr restore --filter-keys "example:00C48C10-B6F4-4750-BDEA-642F1A96A3AB" }}
   {{--disable-views --disable-ft-indexes --disable-ft-alias --disable-analytics --disable-eventing }}
   --start "2022-11-09T22_40_02.19803404Z" --end "2022-11-17T22_29_27.47060691Z"
2. but the same key is found and restored by cbbackupmgr restore  upon restricting its work on one backup (in this case, the full one)

cbbackupmgr restore --filter-keys "example:00C48C10-B6F4-4750-BDEA-642F1A96A3AB" --disable-views --disable-ft-indexes --disable-ft-alias --disable-analytics --disable-eventing  --start "2022-11-09T22_40_02.19803404Z" --end "2022-11-17T22_29_27.47060691Z"

Under an apparently identical scheme, cbbackupmgr restore __ between the full backup and a  __ later incremental one for a whole bucket (i.e., without -filter-keys option)seems to miss a huge number of items (no -force-update option is used): millions to tens of thousands  mutations and few thousands deletions are restored (with 0 failures) after invoking cbbackupmgr restore on the same backup files (full or incremental), but one backup at a time, i.e. with identically valued options

--start "backup_filename" --end "backup_filename"