A warning about the neighbouring problem, because people arrive at this from the other direction and it is genuinely worse.
On distributions using system packages, an upgrade around this change can fail during package configuration — the post-install step tries to move the bundled plugins directory aside, finds it is not empty, and stops. The package is then left half-configured, and because package managers process everything as a batch, the whole upgrade run is now wedged and refuses to proceed until it is resolved.
The thing not to do is what the error tempts you into: editing the maintainer script to skip the failing line. It gets you past the immediate error, and it does it by not performing a step the package thought was necessary, on a machine you now cannot reason about. Whatever the next upgrade assumes about that directory is now untrue.
The safer shape is to sort out the directory the script is complaining about first, then let the original script run. Take a copy of it somewhere else before you touch anything, so "put it back" stays available.
And the general habit this argues for: snapshot before a minor upgrade of anything that owns its own plugin directory. Not because minor upgrades are risky in themselves, but because packaging changes hide inside them, and a packaging change is the kind that leaves the machine in a state no runbook covers.