I think what your doing is fraught with problems. Using console IO and stdio on the same handle is much like using sysread and friends alongside <READ> on the same filehandle; it may work some of the time, but the interaction between the two modes of operation will eventualy conflict and produce undefined (and possibly undefinable) results. That's not to say you couldn't make it work, but your unlikely to get much support doing so.

The Console api's allow a process to effectively have multiple consoles. When you create a new console specifying one of the standard handles, you are effectively tying that handle to the Console api's. As you haven't specified any modes, you are getting

GENERIC_READ | GENERIC_WRITE | FILE_SHARE_READ | FILE_SHARE_WRITE by default.

Once you so tie the handle to a console, unless you take steps to untie it, when the console handle goes out of scope, the handle is effectively thrown away (read:closed), hence why making the handle global with our delays the onset of the problem.

I really think that unless you intend using the Console Api's for all your terminal IO, then you would save yourself a lot of grief by solving your problems with Term::ReadKey. Mixing API's the way you are is only likely to lead to more frustration.