This turns out to be an issue with an entirely different value.  I don't fully understand why this is happening.

I'm calling a shadow method with a PyObject* value:

    result = py_target->inst_copy(source->handler_instance);

In the SWIG function for that method, it starts out like this:

   int SwigDirector_ICamera::inst_copy(PyObject *src) {
     int c_result;
     swig::SwigVar_PyObject obj0;
     obj0 = src;
     ...

The "src" object on input has a reference count of 5, but on exit (when SwigVar_PyObject is destroyed), the reference count is decremented to 4.  Huh?

Within the function, nothing is done with this SwigVar_PyObject instance except to pass it on to Python:

  swig::SwigVar_PyObject result = PyObject_CallMethod(swig_get_self(), (char *)"inst_copy", (char *)"(O)" ,(PyObject *)obj0);

So no other opportunities for incrementing its reference count exist.  Eventually, this theft of a reference count causes the object to be released by Python because it drops to zero, and subsequent attempts in my C++ code to use it meet with a crash, because I'm left holding a dangling pointer.

SwigVar_PyObject assumes "ownership" of the object -- because it modifies the object's reference count -- without what would appear to be a proper increment.  Do I have to increment myself all PyObject*'s that I provide to the SWIG layer "just in case"?  Or, can I put something into my interface file that tells SWIG that specific instances should be unmanaged (e.g., change the "swig::SwigVar_PyObject" type to be just PyObject*)?