It's all about scope.  Global and Local.

variablename="hello" will ONLY apply to the existing function within the existing component.  Of course you can call external component functions but that complicates matters for this explanation, and external references to functions will give you confusion/troublesome error messages with no direct indication of where a problem is.

m.variablename="hello" is global ONLY to the existing component.  All functions within that component will have access to this variable if it has been set.  If it hasn't been set then it will be set to be a global component variable limited to that component.  If it is in the Main thread then it will be global to the main thread (before scenegraph starts up).  From the main thread you can set variables to the global object itself to give global access to the scenegraph thread from any function through the m.global namespace

m.top is another way to grab a variable from a scenegraph component

m.global = screen.getGlobalNode()
m.global.variablename="hello" will be accessible to any function in any scenegraph component.

You can read more on this here:
https://sdkdocs.roku.com/display/sdkdoc/SceneGraph+Data+Scoping

The reason for this is it seems most programmers believe that to have a global variable is the worst possible thing you can do because they have trouble keeping track of the program flow they are working on, or they prefer to use the same variable names repeatedly throughout their code for different purposes.  However, by not keeping as much data globally accessible throughout the program you can minimize memory usage by constantly creating placeholder/temp variables and discarding them as quickly as possible.  So it's a point of contention as to which method is better.  The end conclusion is this is how the firmware forces you to do things so you have little choice here.

Added reading -- 
Globals are bad -- https://en.wikibooks.org/wiki/A-level_C ... _variables

Globals are good -- https://forums.ni.com/t5/LabVIEW/Global ... -p/1528392

Globals are evil -- http://www.learncpp.com/cpp-tutorial/4- ... -are-evil/

Globals are actually good -- DOI: 10.1002/spe.4380130508

"Much modern programming theory places emphasis on the localization of the use of program variables and only occasionally justifies the use of global variables. This paper does not support that point of view. In fact it advocates exactly the reverse."

Sure, using Global variables could lead to inadvertent corruption of pertinent data accessing them within subroutines or via typos/carelessness, but they do exist for a reason - and sometimes globals, particularly cached globals that you refer to many times can be accessed quicker than local variables - (cited by Google Chrome and other design platforms), but it is mute as long as the standards and compiler checks are in place on roku.  It is good global access is available for the cases where it is most needed.

"destruk" wrote:
Added reading -- 
Globals are bad -- https://en.wikibooks.org/wiki/A-level_C ... _variables

Globals are good -- https://forums.ni.com/t5/LabVIEW/Global ... -p/1528392

Globals are evil -- http://www.learncpp.com/cpp-tutorial/4- ... -are-evil/

Globals are actually good -- DOI: 10.1002/spe.4380130508

Thanks for those. I vote good.

Great replies destruk! Thanks for taking the time to explain it with examples. I'll give those links a read as well.