What if $device is somehow invalid or empty?
Could some checking be implemented?
Currently get_device_from_partition is called only once
so the caller code could be enhanced to do some error handling
if get_device_from_partition returns non-zero exit value
or if get_device_from_partition output is empty if that indicates an error.

@jsmeix

$device can't be empty here, it has been created in this function, unless the caller has provided an empty $1. Should we protect against that?

Concerning validity, we could check if the device actually exists and is a block device.

You may catch empty $1 after partition_block_device=$1 with something like

contains_visible_char "$partition_block_device" || BugError "Empty string passed to get_device_from_partition"

or probably even better

test -b "$partition_block_device" || BugError "get_device_from_partition called with '$partition_block_device' that is no block device"

which also catches when $1 is empty or only blanks and it shows that in the error message like

get_device_from_partition called with '' that is no block device

or

get_device_from_partition called with ' ' that is no block device

I tested that test -b behaves well also for symlinks
(at least on my openSUSE Leap 15.2 system):

# ls -l /dev/disk/by-id/wwn-0x5000039462b83c55-part1 | grep sda1
lrwxrwxrwx 1 root root 10 Apr 30 07:36 /dev/disk/by-id/wwn-0x5000039462b83c55-part1 -> ../../sda1

# test -b /dev/disk/by-id/wwn-0x5000039462b83c55-part1 && echo y || echo n
y

Additionally the current "string munging" implementation
may result a $device string that is not a block device
so something like

test -b "$device" && echo $device

(test -b "$device" returns 1 when it is no block device)
as last command in the function
makes the function return 1 in case of errors
so that its caller can do whatever is best in the caller's environment.

Note that quoting is crucial here because

# test -b qqq && echo y || echo n
n

# test -b     && echo y || echo n
y

# test -b " " && echo y || echo n
n

i.e. test -b returns 0 when its unquoted argument is empty or only blanks.

Concerning invalid block devices, how does disk mapping work when block devices in the original system are mapped to different names in the rescue system? Is the layout and mapping regenerated to refer to the mapped names, or does it contain the original names and one has to map them after resolving dependences?
If the latter, it will have impact on the desirability of validation in this function, as it will be legitimate to handle device names that do not correspond to actual existing devices.

Weekend is near so only a quick reply off the top of my head:

When things fail with errors because of disk mappings
it is still better than to silently proceed with wrong data.
I prefer user reports where things fail with clear error messages
over user reports when things fail in weird inexplicable ways,
cf. "Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style

In migration mode "all needed files" (whatever that exactly means in practice ;-)
should be adapted during "rear recover".

The starting point is layout/prepare/default/300_map_disks.sh and
the actual mapping happens via layout/prepare/default/320_apply_mappings.sh
which contains

for file_to_migrate in "$LAYOUT_FILE" "$original_disk_space_usage_file" "$rescue_config_file" ; do
...
    ... apply_layout_mappings "$file_to_migrate" ...

so as far as it looks there mappings are only applied to
disklayout.conf layout/config/df.txt /etc/rear/rescue.conf

I assume those three files are usually sufficient
but I don't know for sure, in particular not for special cases.

Searching the ReaR scripts for apply_layout_mappings
(that is the function that does the actual works)
finds that apply_layout_mappings is also called during "rear recover" in
finalize/GNU/Linux/250_migrate_disk_devices_layout.sh
and
finalize/GNU/Linux/260_rename_diskbyid.sh
where a lot more files (in particular restored bootloader config files)
get possibly adapted.

I am not a sufficient UEFI booting expert to know if there are missing
efibootmgr and/or EFI bootloader related files that would need to be adapted.

As far as I understand the code in finalize/Linux-i386/670_run_efibootmgr.sh
it seems disk mapping cannot affect how efibootmgr is called there
because it seems the code in finalize/Linux-i386/670_run_efibootmgr.sh
works directly on the actual state in the currently running recovery system because
it seems all is based on where ESP is mounted in the currently running recovery system
so nothing possibly outdated of how things have been on the original system is used.

As far as I understand the code in finalize/Linux-i386/670_run_efibootmgr.sh
it seems disk mapping cannot affect how efibootmgr is called there
because it seems the code in finalize/Linux-i386/670_run_efibootmgr.sh
works directly on the actual state in the currently running recovery system because
it seems all is based on where ESP is mounted in the currently running recovery system

After this proposed change, the code will use disk mapping (and not just the actual state). But, thanks to apply_layout_mappings being called earlier, the disk mappings should be in sync with the current disk names, so there should be no problem.

I am surprised a bit though that apply_layout_mappings gets called multiple times.

Regarding "something is done multiple times" and similar things in ReaR:
Welcome to surprising adventures with grown code over many years by various contributors ;-)

I think ReaR is a perfect bazaar as in
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

I added both checks that you suggested (for get_device_from_partition input and result).