The tracking/stepping output with verbosity level 3 or higher is malformed, due to how the data is streamed to std::cout. The relevant code bits are in source/tracking/src/G4SteppingVerbose.cc, for example in line 459:

G4cout << "         Position - x (mm)   : "
        << std::setw(20) << fStep->GetPreStepPoint()->GetPosition().x()
        << std::setw(20) << fStep->GetPostStepPoint()->GetPosition().x() << G4endl;

Due to how std::setw() works, this can lead to cases where the actual printed width is longer than 20 chars, and to cases where the two printed numbers are not separated by any whitespace. This can lead to strings like

         Position - x (mm)   : 0.0088999911328357940.008899991132835794

         Position - x (mm)   : -0.008899991132835794-0.008899991132835794

         Position - x (mm)   : -0.008899991132835794e-05-0.008899991132835794e-08

         Position - x (mm)   : -0.008899991132835794e-050.008899991132835794e-08

and so on. The easiest fix to make these lines properly read- and parseable is to add a whitespace in between:

G4cout << "         Position - x (mm)   : "
        << std::setw(20) << fStep->GetPreStepPoint()->GetPosition().x() << " " <<
        << std::setw(20) << fStep->GetPostStepPoint()->GetPosition().x() << G4endl;

This needs to be done at all relevant blocks in all files which print stepping output, though. I was able to parse the strings using a regular expression, "[+-]?\d+\.?\d*(?!\.)(?:e[+-]?)?\d*(?!\.)", but for example a case like

         Position - x (mm)   : 0.0088999911328357940.008899991132835794

can only be parsed correctly if one assumes the second number starts with a leading zero (which, in this case, it obviously does).

Similar problems occur if volume names have more than 20 characters.

I'd consider this a bug because it makes the output unnecessarily complex to parse.