No, but a library I link in later might have a global variable called "mode" which conflicts with my own. That's one reason to avoid using globals.
There are valid reasons to broaden the scope of data. From your description, the data cries out to be module scope.
The device I'm programming is a light and sound effects board. My main program is skeleton code which will be used in every case. I then have a specific function, we'll call it statemachine(), which is different for every project. That code runs in the main loop, uses the timing code from the main loop, uses the inputs read in the main loop, and then does whatever it wants to do with that data.
My goal is to get the code to a state where the only function you need to change is that one statemachine() function, and maybe a few helper function to keep the code neat. But having a bunch of globals in the main program that have to be altered as well is a no-no. I don't want myself or the end user to have to alter the main program. That makes a mess of things.
Since this mode variable is specific to the project, I don't want it mixed in with the other global variables.
I guess the ideal way to handle this would be to have each project be it's own library so it can have its own globals, but I ran into issues with that. I don't remember what those issues were, but I don't have time right now to muck about with it and try to shove it all into a separate library again.
Anyway that's why I don't want to make the variable global.
You have an interesting definition of "not small". We are talking about an AVR processor.
I meant relative to your typical Arduino project that blinks a few LEDs. Also, I've got a 1284P in my board so I do have a little more program space and ram to work with than is typical. 
Is it likely some other lib uses a global mode variable and modifies it? Probably not. Would the compiler throw an error even if it did? Maybe.
A problem easily avoided by putting "static" in front of mode.
I don't understand. Static on a global variable?