I reported this bug privately some time ago. I still see the same strange behavior in 4.9.6.p01.

A particle is not scored when step length proposed by StepLimiter lands exactly on a geometry boundary.
One can produce this bug as follows:
Send a proton though vacuum at a sensitive volume with boundary exactly 100 cm from the source.
Include the step limiter process in your physics.
Set step limitation to 100 cm (or any even division of 100, such as 10. cm).
The sensitive volume will not record the particle.
Change step limitation to 99. cm (or some other number such that the proposed step will not exactly line up with the sensitive detector).
The sensitive volume will record the particle.

The following is the last analysis from Hisaya when he was studying the issue:

If the step length proposed by StepLimiter is equal to the length to
the next boundary, the volume in the post-step points to the volume over
the boundary (i.e. Touchable has been updated), but the StepStatus is
not set to 'GeomBoundary'. It causes serious effects to scoring and
optical processes.

I investigated and found the origin of this problem.
'GeomBoundary' is set by SteppingManager if the process which propose
the shortest step length is transportation. If one more processes
propose the same shortest step length, the first process in sequence of
PostStepGPIL and AlongStep is selected as the process which defines the
step length. (Note that: AlongStepGPIL of transportation is invoked at
last and proposed step length is always equal to shortest step length. )
So, StepLimiter is selected in the above case and the step status is set
to 'PostStepDoItProc'. In the PostSetpDoIt of transportation, However,
the touchable is updated because G4Transportation::fGeometryLimitedStep
flag is set in AlongStepGPIL.

I'd propose to modify PostStepDoIt of transportation as follows in
order to solve this problem.

if(fGeometryLimitedStep)
{
// fCurrentTouchable will now become the previous touchable,
// and what was the previous will be freed.

should be

if ( (aStep.GetPostStepPoint()->GetStepStatus() == fGeomBoundary) ||
(aStep.GetPostStepPoint()->GetStepStatus() == fGeomBoundary) )
{
// fCurrentTouchable will now become the previous touchable,
// and what was the previous will be freed.

I've checked that the strange step disappears with above modification.
But I'm not sure that this modification works in all cases and there
is no side effect.