I would like to make an additional suggestion.
(and I implemented this yesterday):

Native namedtuple (not a derived class) can be made much simpler to handle
when no module and class machinery is involved at all.

The way I implemented it has no need for sys._getframes, and it does
not store a reference to the class at all.

The advantage of doing so is that this maximizes the compatibility
with ordinary tuples. Ordinary tuples have no pickling issue at all,
and this way the named tuple should behave as well.

My implementation re-creates the namedtuple classes on the fly by a
function in __reduce_ex__. There is no speed penalty for this because
of caching the classes by their unique name and set of field names.

This is IMHO the way things should work:
A namedtuple replaces a builtin type, so it has the same pickling
behavior: nothing needed.

Rationale:
tuples are used everywhere and dynamically. namedtuple should be as
compatible to that as possible. By having to specify  a module etc., this dynamic is partially lost.

Limitation:
When a class is derived from namedtuple, pickling support is no longer
automated. This is compatible with ordinary tuples as well.

Cheers - Chris