@dawehner pointed me to #2018493: FATAL error when a view with a placed block is disabled or removed, which made me realize that we're letting other code assume things about how block plugins get placed and used that they should not be assuming. specifically, this code. that code deletes all block plugin instances that are based on a particular views block display when that display is removed. this is the outcome we want, but it's not the way to achieve it - even after that patch goes in.
the problem is that any other system that might be wanting to create or manage block instances in its own way - like, say, how princess does right now - is left out in the cold. so, this behavior needs to be changed to invoke a hook with the ID of the disappearing block plugin, so that all block implementations can listen and update their datastructures accordingly.
moreover, that hook should have a flag that is used to indicate whether the disappearance of the block plugin identified by the provided ID is (more) permanent or temporary. e.g., deleting a view with a block display is a permanent deletion, but merely disabling the block display on that view is equally temporary (disabling a module is a tougher question, but the flag still helps us be more granular) this way, the hook implementations can potentially choose to 'stash' the created block instances in some way for the temporary case, rather than deleting it, which could be a big gotcha for users.
now, yes, the example i linked to above is within block.module, but that specific plugin's responsibility is to (ultimately) provide block plugins via a derivative - which means it's on the block-plugin-producing side of block.module's responsibility, not the block-instance-placing-and-management side. and keeping block plugins, or their producers, from assuming anything about block plugin instance storage, is the crux of this issue.