The attached gcode was generated by PS 2.3.0 and has not been modified in any way.

That's not entirely true. The issue seems to be triggered by the comments added by displaylayerprogress Octoprint plugin.

; BEGIN DISPLAYLAYERPROGRESS SETTINGS
; DisplayLayerProgress_layerIndicatorProcessed = true
; END   DISPLAYLAYERPROGRESS SETTINGS

Ah - yes, unusually I'd downloaded that gcode from octo so I was certain it was what generated a particular print (a potential FW issue that's under investigation). I'd forgotten about that, and also I had no idea that octo plugins can modify stored files. Well spotted. But I assume that ideally those additional comments shouldn't choke the gcode viewer?

How about PS emits specific start and end marker comments for its block of config comments? Then when reading, comments outside this block could be ignored. If the start and end markers are absent, then fallback to the current behaviour, thus giving backwards compatibility with "well-formed" gcode generated by earlier versions of PS/Slic3r. The start and end markers could be in standard config format so that they are simply ignored by older versions of PS. I tried surrounding the config block with:

; dummy_start_of_config = 0

and

; dummy_end_of_config = 0

and this is loaded fine by the current version of the gcode viewer - this is without the original offending comment block of course, but it demonstrates backwards compatibility for this approach.

Improved with e947a29

1) Starting with this commit, configuration block exported into G-code
   is delimited by "; prusaslicer_config = begin" and "; prusaslicer_config = end".
   These delimiters look like any other key / value configuration pairs
   on purpose to be compatible with older PrusaSlicer config parsing from G-code.
2) Config parser from G-code newly searches for "; generated by ..."
   comment over the complete G-code, thus it is compatible with various
   post processing scripts extending the G-code at the start.
3) Config parser from G-code parses PrusaSlicer version from
   the "; generated by PrusaSlicer ...." header and if the G-code was
   generated by PrusaSlicer 2.4.0-alpha0 and newer, it expects that
   the G-code already contains the "; prusaslicer_config = begin / end"
   tags and it relies on these tags to extract configuration.
4) A new simple and robust parser was written for reading project configuration
   from 3MF / AMF, while a heuristic parser to read config from G-code located
   at the end of the G-code file was used before.

If you have generated G-codes with PrusaSlicer 2.4.0-alpha0 before this commit, the delimiters are missing and you will get an error message. That's the risk of using pre-alphas.

Implemented with PrusaSlicer 2.4.0-alpha1.
Closing.