zypper locks don't allow upgrading into specified version

[pfee]

Experimenting with zypper version specific locks, I find that if applied to an already installed package, they lock that version in place. However if applied to a not-yet-installed version, they lock out installation of that version.

For example:

$ zypper se -s gdbserver
Loading repository data...
Reading installed packages...

S  | Name      | Type    | Version            | Arch   | Repository
---+-----------+---------+--------------------+--------+-------------------------------------------------------------
v  | gdbserver | package | 12.1-150400.15.9.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
il | gdbserver | package | 12.1-150400.15.6.1 | x86_64 | Main Repository

Issuing zypper up gdbserver will prevent upgrade (good, locks working as desired). However if we move the lock to a version not yet installed, the lock blocks the update.

$ sudo zypper rl gdbserver=12.1-150400.15.6.1
1 lock has been successfully removed.
$ sudo zypper al gdbserver=12.1-150400.15.9.1
Specified lock has been successfully added.
$ zypper se -s gdbserver
Loading repository data...
Reading installed packages...

S  | Name      | Type    | Version            | Arch   | Repository
---+-----------+---------+--------------------+--------+-------------------------------------------------------------
vl | gdbserver | package | 12.1-150400.15.9.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | gdbserver | package | 12.1-150400.15.6.1 | x86_64 | Main Repository
$ sudo zypper up gdbserver
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: conflicting requests
 Solution 1: do not ask to install a solvable providing gdbserver.x86_64 = 12.1-150400.15.9.1
 Solution 2: remove lock to allow installation of gdbserver-12.1-150400.15.9.1.x86_64[repo-sle-update]

Choose from above solutions by number or cancel [1/2/c/d/?] (c): 

This seems unhelpful. Once you're in you're locked in, but if you're out you're locked out. Wouldn't it be preferable to allow upgrade "into" the lock?

[pfee]

Following feedback on a related ticket, this is intended behaviour. Hence closing this ticket.