To provide a more detail beyond what Simon said (a bit technical, but useful to understand):
Digital text has an encoded form, which almost ubiquitously is Unicode. This assigns a numeric encoding for every character of every writing system, and that is how characters are stored in a computer or transmitted between computers. For example, the numeric value 65 (in Unicode hex notation, U+0041) is used as the encoded representation for Latin capital letter "A"; the value 3,627 (U+0E2B) is used to represent Thai letter ha "ห", etc.
Everything that happens when entering, processing, or displaying text is done in terms of the encoded representation inside the computer. When you press a key on a keyboard and see something display on the screen, there is not a direct connection from keyboard to font. Rather there are two sequential interactions: the keypress results in generating the encoded representation stored in the computer, then a separate process takes that encoded representation and displays it on the screen using a font.
The important point here is that there is no direct connection between a shift key or any other key and a font. The effect of pressing keys is to generate Unicode encoded sequences stored in the computer, and what the effect is of any key depends entirely on the programming of a keyboard input method. In principle, a keyboard input method can be created to allow two shift keys to behave differently in terms of the encoded sequences that get generated, but that is not common. On the other hand, it is not uncommon for the right Alt key on a PC to have different effects than the left Alt key.
When creating a font, you generally should not be thinking about keying sequences that produce different visual results. Rather, you should think in terms of Unicode character sequences, and creating a font that will produce a display of text that reflects the Unicode-defined semantics of the encoded characters. Then, if you need a particular keying experience, there would be an independent exercise of creating an input method that produces a Unicode character sequence from the desired keypress sequences.
If you create a font that produces some custom association between keystrokes and display, then most likely what you will have done is to create a font that assigns glyphs to Unicode encoding in a misaligned way, so that the font does not match the underlying Unicode semantics of the data. That will make the font and the data produce unusable by anyone except if displayed by that font.
Back in 2001, I wrote a chapter in a book explaining these concepts; it's available online here:
Software that supports variable fonts is likely to support whatever axes are in a given font, custom or registered, in terms of exposing in UI and ability to select and use variants.
But software is not going to know what a custom axis is doing, and so cannot do anything with it beyond allowing manual selection of an axis value by the author. Even if two fonts have custom axes using the same axis tag, software can't assume there is any connection between them, so if you switch from one to another any setting for custom axes will likely be cleared and need to be redone.