Note: the problems described below are seen under both geant4.2.0/DEC-cxx and
geant4.1.1/Linux-g++.  I see it in both my own simulation and in exampleN06.

In a simulation of internal opticalphoton reflections in a photomultiplier tube,
I observed some incorrect behavior when photons inside a volume reflect off the
boundary of the volume.  My photomultiplier is implemented as a glass-filled
volume which has a vacuum-filled daughter.  The vacuum-filled volume itself has
a metal-filled daughter representing the dynode stack.  When I fire optical
photons from within the vacuum towards the front of the PMT, the photons either
refract out into the glass or reflect back into the vacuum.  When they refract,
the CurrentTouchable on the following step points to the glass envelope, as it
should.  When the photons reflect, the CurrentTouchable on the next step is
incorrectly changed to point to the glass-filled mother of the vacuum-filled
volume from which the photon came.  The track of the photon then passes through
the dynode as if it weren't there, reaching the boundary of the glass on the far
side.  In other words, the Transportation process changes the CurrentTouchable
to the mother volume regardless of whether the photon has refracted.  Obviously,
when photons reflect, we don't want Transportation to change the current volume.

Similar behavior can be seen in exampleN06.  First, make a simple change to
ExN06PrimaryGeneratorAction.cc to allow the /gun/XXX commands to work: simply
take the "particleGun->SetParticleXXXX" code out of GeneratePrimaries and put it
in the constructor instead.  Then the problem can be demonstrated with the
following script:

/run/initialize
/gun/particle opticalphoton
/gun/position -5.0 -4.9 0 m
/gun/direction 1.0 -1.0 0
/gun/energy 2.5 eV
/gun/polarization 0 0 1
/tracking/verbose 1
/run/beamOn 10

What I see when I do this is the photon travels to the boundary of the water
tank and either refracts or reflects.  When it reflects, it changes its
direction as it should, but ends up "located" in the mother of the water tank.
It then travels zero distance before encountering the water tank again.  Then,
it REFRACTS as it "enters" the water tank, ending up with a silly value for the
momentum direction.

I believe I understand why this happens.  The problem is that the Navigator and
the Transportation process both believe this is a "geometrically limited step".
Accordingly, the Transportation process calls
G4Navigator::LocateGlobalPointAndUpdateTouchable() to find the newly entered
volume, which is especially careful to block the old volume from consideration
as being the newly entered volume.

It seems that some way needs to be found to tell Transportation to change its
mind and unset fGeometryLimitedStep when reflection occurs.  This may also
result in a slight performance advantage, since I suspect the
LocateGlobalPointXXX functions might be expensive and it's nice not to call them
if you don't have to.

By the way, I wish "bugzilla" allowed one to select more than one component.  I
wish I could select both "processes/optical" and "processes/transportation" for
this one.

Please let me know soon if there's a simple fix! :-)