I suppose that the loss of source area could happen if the tool context is lost.
Do you see the active tool switching to something else when you move the pen out
of the tablet?  Do you see any changes in the toolbox or tool options?

Yes, the active tool seems to switch to the paintbrush when the pen is moved out
of range of the tablet. I tested this with the bucket fill tool, the crop tool,
and the clone tool. 

In 2.2.3, when the pen moves back into range of the tablet, the active tool
switches back to whatever you were using in the first place. But in the case of
the clone tool, the selection is lost.

I *think* in 2.2.1 (I only used it with my tablet briefly until I realized there
was an update available), when the pen would move out of range of the tablet,
the tool would switch to the paintbursh, but would *not* automatically switch
back when the pen was moved back into range. I could be wrong about this tho.

In the tools pallet, when the pen is moved away from the tablet, whichever tool
is selected (ie: it looks like a depressed button) changes from the tool you're
using to the brush. It then changes back (in 2.2.3) when the pen gets back into
range.

I haven't had the opportunity to test this with my tablet yet, but I suppose
that what happens is this: when you move the pen out of range, the tool switches
from the one assigned to the extended input device (tablet pen) to the one
assigned to the default input device (mouse).  You should be able to see that
clearly if you open the dialog showing the status of the various input devices:
you will see that the current device changes and this results in a change of
tool (and brush, pattern, ...).

The annoying thing is that this temporary switch of tool context seems to cause
the source area for the clone tool to be lost.  It would be nice if that could
be avoided by keeping this useful info in the tool context for a while (for
example, at least until the other tool is really used to perform some operation)

Yes, that appears to be what is happening. When the pen is in range of the
tablet, either the "WACOM Tablet Pressure Stylus" or "WACOM Tablet Eraser
Stylus" is active (depending on which end of the pen is in range). When the pen
moves out of range, the active device changes to "Core Pointer". When you move
the pen back into range, it becomes the active device again.

*** Bug 171725 has been marked as a duplicate of this bug. ***

I have looked into this and the reason a tool switch occurs when the pen is
lifted is this:

GTK+ on Windows initializes the tablet to use a so called system context, which
means that the tablet driver will move the system cursor. This makes the tablet
send both regular mouse movement events and tablet movement events to GTK+.
Since this is not desirable, the regular mouse events are ignored by GTK+ as
long as the pen is on the tablet (in proximity).

The problem is that when lifting the pen, sometimes a mouse move event can get
received just _after_ the proximity out event is received, which makes GTK+
treat it as a normal mouse movement and send a core pointer event.

This looks fixable by slightly delaying the handling of the proximity out
events, and I have an experimental patch for GTK+ that does just that.

I'll reassign this to GTK+ and provide a patch for discussion shortly. I hope
this is acceptable to the GIMP maintainers.

I will also reopen bug #171725 ("clone source is lost on tool change"), since
that still seems to be a valid bug report or enhancement request for GIMP.

Created attachment 49090 [details] [review]
Patch for discussion, delays proximity out handling

Here's a possible way to fix it. The main thing I think need review on this
patch is the fact that I've used g_timeout_add/g_source_remove in the GDK win32
backend, and I don't know if this is acceptable (it requires a mainloop,
doesn't it?). If that is not acceptable, I can rewrite the patch to use the
Win32 SetTimer/KillTimer API functions instead. Please comment.

Could any GTK+ maintainer please tell me if it is acceptable or not to use
g_timeout_add in the GDK win32 backend?

Personally I think it would be OK since gdk/gdkwindow uses g_idle_add_full and
g_source_remove.

Tor, what do you think? Does the attached patch look OK?

Looks fine to me. Perhaps 500 ms is a bit too long, though? 

Yeah I guess so, that number was pretty arbitrarily chosen. I'll attach a new
patch that makes it a #define, and cuts it down to 200 ms. I don't think many
people will be able to drop the pen and pick up the mouse in less than 200 ms :)

Created attachment 49872 [details] [review]
Updated patch

Now with ChangeLog entry and lowered delay.

Tested with my Wacom Graphire 3, driver version 4.90-3.

Thanks! Patch applied to gtk-2-6 and HEAD.