This patch enhances warnings.warn() in the following
way: The stacklevel passed in may be negative. In that
case the call stack is searched for the innermost frame
whose module name differs in the first -stacklevel
components. This frame will be used in the report.

So when you have the following call stack:
m1.f()
m1.m11.f()
m1.m12.f()
m2.m21.f()
m2.m22.f()

and the innermost function() m2.m22.f() call
warnings.warn() with a stacklevel of -2 the frame
reported will be from m1.m12.f(), because it is the
first one from outside the m2 package.

I don't know how desireable this feature is, but
I think that a better solution would be to add
a new parameter to warnings.warn(), instead of
reusing the old one.

Also, your description is wrong; when warn() in
your example is called with stacklevel -2, the
reported frame is m2.m21.f().  To get your result,
you have to call warn() with stacklevel -1.

I think that a better solution would be to add
a skipmodules='moduleprefix' parameter to the
warn() function.  warn() would then simply look
for the first frame whose module name doesn't
start with this prefix.
 

Here's an updated patch that implements your suggestion: skipmodules is a regular expression. Any module whose name matches the RE will be skipped when determining the stacklevel.
File Added: diff2.txt

Looks good to me.  I like that skipmodules is a
regular expression, but I don't know how will it
affect the intended rewrite in C:

http://www.python.org/sf/1631171

It would be nice if the documentation mentioned
what is the interaction between stacklevel and
skipmodules parameters, at least something like:

"If you want to issue a warning outside your module,
and you don't know how many frames will have to be
skipped for that, pass some big integer for stacklevel"

If this patch is accepted, it should be put to use in
the _struct module:

>>> struct.Struct("<l").pack(4023029188) # note: module is sys
sys:1: DeprecationWarning: struct integer overflow masking is deprecated

Patch has tests, needs updating.

See similar http://bugs.python.org/issue25216