Thanks, @fsmithred!
I followed this advice, event though it shows another theme!
My problem was not old/new naming convention, but changing interface names between boot - not daily though
and a quick reboot is not an answer. But I looked at this kernel commandline option and it seems not to have any effect!
But I found 70-persistent-net.rules, something, I've not regarded before.
Astroundingly, the mapping, applied in this file, does NOT fit the reality completely, there is an exception for one interface.
Then I changed the rules/names, but the problem persists. Then I enabled udev debug logging and saw, that the interface,
which hasnt followed the rule, was renamed two times: From eth0 to eth2, the from eth2 to eth3.
"Predictbale interface names" .....
Anyway, which kernel commandline applied.
Additionally, I found, that there COULD be "net.naming-scheme=v250", according to this thread:
udevd produce same ID_NET_NAME_SLOT for different NIC, so break rename #28929 :
https://github.com/systemd/systemd/issues/28929
But from this thread, I found a hint: "udevadm test-builtin" and I used it like this:

$ udevadm test-builtin net_id /sys/class/net/gif0 (where gif0 is now my 10GbE-IF)
calling: test-builtin
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes
Load module index
ID_NET_NAME_MAC=enx001999c13f23
ID_OUI_FROM_DATABASE=Fujitsu Technology Solutions GmbH
ID_NET_NAME_PATH=enp4s0f0
Unload module index

This <enp4s0f0> (under: ID_NET_NAME_PATH) is probably the original IF-name and could explain, why
the "70-persistent-net.rules" cannot work:
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" - because they trigger (not!) on interface
names, which do not exist?
After I enabled udev debug logging, I have to look deeper at systemstart in the next days.
So wether "net.naming-scheme=v250" nor "net.ifnames=1" made something!
To udev logging: The shown output ("=== trie on-disk ===") appears in LSPCI too:

08:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes

at the end of the list of network cards.

For the moment, I choosed a completely different set of names (eno0 for MoBo-IF, eif<N>
for the ethernet (better: 1Gbe) and gif<N> for the 10GbE interfaces. And these coming - at least
for the moment - up with exactly this names without any problem.

The drama will probably start, if I now start setting the "sriov_numvfs"
variable to get man VFs (asked a question in another part of this forum).

Install and check out its man pages (ifrename and iftab).

EDIT: with ifrename you would not have add that boot parameter.

In devuan, with eudev you get the old names....

@fsmithred
Thanks for the good explanation.

a)
How can I find out, what the interfaces will actually be called without modifying the _cmdline_?
b)
and then modify the relevant files  (sed ... s/eth0/enpxxx/ somefile)
c)
If I could give it a try modifying / restarting without loosing connection to my remotes without screen?

In debian, with udev you get the new names (enpblahblahblah) unless you boot with 'net.ifnames=0' to preserve the old names (eth0...)

In devuan, with eudev you get the old names (eth0...) unless you boot with 'net.ifnames=1'.   Add that to the boot command in /etc/default/grub like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet,net.ifnames=1"

and then run update-grub

You will need to edit any scripts you've written that reference the interfaces by the old names.

6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

on a ASRock X570M Pro4.
The situation is to see, if one looks into '/sys/class/net', here two examples.

##Previous boot:

##eth0 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.0/net/eth0    <==
##eth1 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.0/net/eth1
##eth2 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.1/net/eth2
##eth3 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:06.0/0000:08:00.0/net/eth3
##eth4 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.1/net/eth4

##Current boot:

eth0 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.0/net/eth0/
eth1 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.1/net/eth1/
eth2 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:06.0/0000:08:00.0/net/eth2/
eth3 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.0/net/eth3/   <==
eth4 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.1/net/eth4/

How can this be fixed?
BTW, the 0000:08:00.0 is the mainboard interface, which I use as basic interface for LAN access.
I could list the pci-device order (and have saved it), but there are never changes.
This is not a desktop, and this behavior makes ssh access impossible!

Regards,
Manfred