`juju deploy bundle` downgrades a charm or switches the charm sources unconditionally

Let's say I have a model deployed by a bundle. After some time, I wanted to apply a hot fix to a specific charm so I did:
juju upgrade-charm <app> --switch ~mynamespace/charm-with-hotfix

On the other day, I just run a bundle again for some changes such as setting one config for another charm or adding a relation from one app to the other. Then Juju executed upgrade-charm with the behavior of `upgrade-charm --switch` even though the user didn't specified it or wanted to do that. Then Juju wiped out the hotfix and applied the default charm which broke the environment by having the original issue again.

From an idempotency point of view, Juju may be doing the right thing. But switching the charm source is a dangerous operation as Juju itself states as follows:

[juju upgrade-charm -h]
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will succeed,
> regardless of potential havoc, so long as the following conditions hold:

So `juju deploy bundle` shouldn't casually add the dangerous `--switch` behavior out of the box, but warn users like the `--trust` flag.

[The actual output]

Let's say this "ubuntu-lite-test-do-not-use" has a hotfix.

$ juju status --format yaml ubuntu-lite | grep charm:
    charm: cs:~johnsca/ubuntu-lite-test-do-not-use-0

$ juju deploy ./bundle_ubuntu.yaml
Resolving charm: cs:~jameinel/ubuntu-lite-7
Executing changes:
- upload charm cs:~jameinel/ubuntu-lite-7 for series bionic
- upgrade ubuntu-lite to use charm cs:~jameinel/ubuntu-lite-7 for series bionic
Deploy of bundle completed.

Then, the charm source has been switched without a warning thus the hotfix is lost.

$ juju status --format yaml ubuntu-lite | grep charm:
    charm: cs:~jameinel/ubuntu-lite-7