When encountering a bug, it helps to determine the minimum needed to invoke the bug.  os.chdir is irrelevant and distracting noise as far as investigating these bugs.  There turns out to be two.  Raw versus cooked mode is also irrelevant, so an 'r' prefix is not needed.  The path separator also seems to not matter.  So we can use '/'.

I did several tests with 3.6 on Windows 10, first in Shell, then a quick confirmation in a fresh editor.  What does matter is the open quote: ', ", ''', or """. When one types a string without completions, the opening quote along with any prefix is colored, as is the subsequent content and closing quote as they are entered.  This should remain true when completions are involved.  It is true for opening """ or ".  For ''' and ', the first action after typing '/' is colored, subsequent actions are not. The action can be either typing a letter or moving the selection in the completion box with up or down arrow.  (Things are different when moving around in a string and forcing completions open with cntl-space.)

When one types a closing quote, the final directory should be completed if it is not already and the completion box closed.  This is true for """ and ", but ''' and ' neither complete nor close.  After a ''', additional characters are also colored.  For "'''/Ga'''me", the "me" are also, improperly, colored and the box remains.

We thus have two bugs: a color but that depends on the number of open quotes and a complete and close bug that depends of the type of open quote.  A single single quote has both.  Thank you for the report.

Colorizer has a pair of symmetrical regexes for single quote strings (possible not complete) and another pair for triple quote strings.  (Symmetrical means identical except for reversing roles of ' and ".)  So it is plausible that these might be the cause of a number-dependent bug.  It has a debug most that could be turned on doing file completion in an editor.