We experienced this problem on database that originates from eZ4 times. But problem is reproducable on fresh content. 

Issue spotted on ibexa/experience v4.3.2 but most likely is reproducable on earlier versions and on ibexa/content.

Scenario to reproduce in my case it was.

1. Add policy to role (content/create)
2. Add subtree limitations. I added two folders one which I will delete later.
3. Save policy.
4. Result: Both folders visible on role view and on role edit.
5. Role update preserves stored subtrees like we expect.

Scenario to break things:

1. I send 'Folder to remove' to trash.
2. Role view shows part of pathstring to removed object but only first part of it (just /Media). But its easy to miss.
3. In edit form:
   1. Tags to remove subtrees are all gone.
   2. Hidden input has no value 

      <input type="hidden" id="update-policy-f106f9a304c98665e3207a357dc0b943_limitations_Subtree_limitationValues" name="update-policy-f106f9a304c98665e3207a357dc0b943[limitations][Subtree][limitationValues]">

1. Submitting the form in this state (if user fail to spot that subtrees are gone) results in complete removal of all previously stored subtree limitations.

I narrowed it down to this function

vendor/ibexa/admin-ui/src/lib/Form/DataTransformer/UDWBasedValueModelTransformer.php:53

        try {
            return array_map(function (string $path) {
                return $this->locationService->loadLocation(
                    $this->extractLocationIdFromPath($path)
                );
            }, $value);
        } catch (NotFoundException $e) {
            return null;
        } catch (UnauthorizedException $e) {
            throw new TransformationFailedException($e->getMessage(), $e->getCode(), $e);
        }

When one NotFound element in collection results in no data passed to form->viewData, resulting in empty form value and possibility to loose stored data. In our case we discovered this on policy with 700+ subtrees.