http://docs.intersystems.com/cache20171/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_operators#GCOS_operators_indirection

Name indirection can substitute only a name value. The second SET command in the following example returns an error message because of the context. When evaluating the expression to the right of the equal sign, Caché interprets @var1 as an indirect reference to a variable name, not a numeric value.

SET var1 = "5"  SET x = @var1*6

SET var1 = "var2",var2 = 5  SET x = @var1*6

This was reported in WRC 895607.

My natural inclination would be to use NameIDX for an index; which goes back to me saying that naming is so unrestricted and easy, earlier.  A lot of my early programming experience came from school, where the Department saddled us with the use of a custom implementation of C++ which forced heavy abstraction with strict definition rules, everything was black-box components.  To keep sane you had to name carefully, I guess I internalized that more than I thought.  Sorry to distract from the discussion.

Honestly, John, the idea of NOT using unique names is foreign to me, I do not understand why someone would be tempted to do so.  To me it would seem illogical to create members with the same name because I would question whether that member's function is needed and makes sense in the design.  Plus, naming is not restrictive so it is too easy to make names unique.  Class,Name, Class.GetName, Class.Names, Class.Name.Assign; I would only confuse myself calling all those just Class.Name and wonder if they are all needed; if Class.GetName will always give me the same as Class.Name, why have it?  Maybe I am missing the point, but that's my take. 

You could also take a look at the ZWELCOME routine and after going through your custom login make use of the one-argument form of $SYSTEM.Security.Login. 

http://docs.intersystems.com/cache20141/csp/docbook/DocBook.UI.Page.cls?KEY=GSTU_customize#GSTU_customize_zlang  Extending Languages with ^%ZLANG Routines.