A decoder (operating in the Marklin/Trix ecosphere) may have any of 4 addressess and some decoders may be provisioned to support one or more of these 4 for use with the different types on controller.

1) MM/FX = MarklinMotorola (1-80) FX (1-255) - implementation limited by decoder version and controller
2) DCC = (1-10239) - implementation limited by decoder version and controller
3) SX = Selectrix V1 or V2
4) mFX = called a mfxUID = based on the decoders serialnumber - e.g. .mfxuid=0x7dfc6cfc

so while it is possible for users to remember 2 digit (MM) and 4 digits (DCC) in a decimal system, it gets a bit demanding to remember 8 hexidecimal characters.

From its first deliver mFX totally insulated the User from the need from knowing the mfxUID by inserting a translating layer that presented itself as a object with a human readable/definable name and a distinctive icon/picture

It was not until about v3.5.6 of the CS2 firmware, that (GUI) Users even became aware of a separate numbering range (starting at 1) as a shortcut.
It was at this firmware update where we saw the (re)introduction of a numeric keypad to emulate the 6021 operation that people were still experiencing withdrawl symptons from.

Comment: However software developers had been aware of this as a locomotive was addressed by it LOCAL UID . e.g. .uid=0x4006
In the CS2 archetecture the mFX address space is referenced from 0x4000 to 0x7FFF (MM =0x0000-0x03FF , SX2=0x8000-0xBFFF, DCC = 0xC000-0xFFFF)
from the CS2 work file ...
lokomotive
.name=218 245-9 DB
.uid=0x4006
.adresse=0x6
.typ=mfx
.sid=0x6
.mfxuid=0x7dfc6cfc
.icon=BR 218 247 5 DB

At this same firmware change we noted that the "address" represented in the settings screen of a mFX decoder changed its meaning.

- Whereas before it used to reflect the MM address of the decoder, (this was just as a nice convenience as users did not have to drill down into the CVs to find it, before taking they loco to a friends 6021 type layout.)
- After the firmware change this address became the local User/Gui/CS2 address as allocated by the CS2 (And no , you cannot set it yourself)
I am reluctant to call this simply a "mfx address", without adding the "local user" or "local CS2" prefix, as there is also a mfxUID and a LocalUID address associated with the same decode.

Looking at the keypad display we note , at the top, the mode may be selected MM, DCC, mfx. (MM equates to fx)

When choosing MFX you may make use of the LocalMFX address for quick reference - reinforcing the comment that this Local address may be different on another CS2.

From the image it can be seen that when local mFX address 6 is selected , the CS2 presents the name and functions of the loco as if you had called it up in the traditional manner.

These addresses WILL (not may) be different, not least because the mfxUID is 8 characters and the local .uid is 4 (and for mfx limited to the 0x4000-0x7FFF address space- for the CS2)
Please also consider that even on the same CS2 the local address may vary - if you do housekeeping and delete unused references only to rediscover decoders/locos in a different order.

However even the local .uid is an intermediate translation step. In my previous post the 0x4006 .uid is represented alongside .addresse/.sid of 6 and a GUI of 6
The GUI value is the decimal conversion of the .sid


And before you say "its just the same but subtract 4000" it is not, as the .uid/.address/.sid are is hexadecimal and the GUI is decimal
This is best considered when we have .ids up to 9 and add one more. in this case the .uid will move to 0x400a ("a" being a "10" in base 16 hexadecimal)


In a prior query there was a reference to Loco Cards.
The Loco Card stores the .addresse value - which is derived from the value that was the .sid on a CS2 , where the loco was discovered, at the time of writing the card.

If you take that card to another CS2 then the CS2 will TRY, in the first instance, to map the .addresse to its own roster (.sid).
However if that .sid is already in use, it will pick the next available one.

Unfortunately , when subsequently reviewing the loco settings to show the "Address" , all you see is the value that the Card requested (.address), not the one that is actually in use (.sid). While these may be the same , on a club CS2 (for example) it probably will not be the same.
I think that showing the .sid (as well) would be more far more meaningful.

So in the following example ... (excerpt from the http://xxx.xxx.xxx.xxx/config/lokomotive.cs2 when browsing to the CS2)

lokomotive
.name=UP 4000 Big Boy
.uid=0x400b
.vorname=
.adresse=0x9
.typ=mfx
.sid=0xb
.mfxuid=0x73ff7a43
.icon=UP 4000 Big Boy


You may use the (6021) keyboard and type in "11" (the decimal value of "b") and this immediately gives you

along with the correct spreed, functions, direction information of the loco

BUT - 3 seconds later it changes to ...

which in my example is the .addresse from the Loco Card.

So, while the speed,functions and directions are retained and usable after this hiccup , seeing the number magically change is a bit scary work out what is happening.
As to WHY it behaves this way, is beyond me. Not least because I may have another "9" so the only way to be sure is to read the name (small print , hard to see etc...)


In summary, the (6021) numeric key pad can be very efficient in selecting a locomotive if you know its .SID.
If you go though an exercise and delete your locos and rediscover them in order you may be able to get your common locomotives with a single digit address. (1-9
although my personal experience is that the lowest number is more likely to be 5),

An extension of this is to somehow get hold of a backup file from a CS2 with 999 locos discovered and massage your own meaningful set of cards.
e.g. BR218 with a .addresse/.sid of "218"