Exercise 3: Two Separate Comments vs. One Nested-Looking Comment — Possible Solution
====================================================================

THE TEST
------------------------------
    parse_css("/* one */ /* two */ p { color: red; }")

RESULT
------------------------------
    Rule.selectors == ['p']    (clean -- no corruption)

TRACING strip_comments'S OWN SCAN POSITION
------------------------------
Two separate comments:  "/* one */ /* two */ p { ... }"
    i=0:  sees '/*' -> finds the NEXT '*/' at the position right
          after "one" -> jumps i past it. Comment #1 fully consumed.
    i is now sitting right after the first "*/", at the space
    before the second "/*".
    Continuing the scan: sees '/*' AGAIN (a fresh, new comment start)
    -> finds ITS OWN matching '*/' (the one after "two") -> jumps
    past it. Comment #2 fully consumed, independently of comment #1.
    Remaining text: " p { color: red; }" -- clean.

One nested-looking comment: "/* outer /* inner */ still outer */ p {...}"
    i=0:  sees '/*' -> finds the NEXT '*/', which is the one after
          "inner" -> jumps i past IT, not past the real intended
          closing "*/" after "still outer".
    The scanner now considers itself OUTSIDE any comment again, at
    the space before "still outer */ p {...}" -- and everything from
    there onward, including the leftover "*/", is copied through as
    literal text.

WHY THIS WORKS AS AN ANSWER
------------------------------
Both cases run through the exact same code, with no branching for
"is this the nested case or the sequential case" -- the difference
in outcome comes entirely from WHERE the second '/*' happens to sit
relative to the scanner's own current position. In the two-comments
case, the second '/*' only appears AFTER the scanner has already
fully closed the first comment and returned to normal, non-comment
scanning -- so it's correctly recognized as the start of an entirely
new, independent comment. In the nested-looking case, the second
'/*' appears WHILE the scanner is still inside the first, unclosed
comment -- and since strip_comments never checks for a second '/*'
while already inside a comment (it's only ever looking for the next
'*/'), that inner '/*' is silently swallowed as ordinary comment
text, and the comment closes one step too early. The scanner's own
total lack of nesting awareness is a constant; it's the SHAPE of the
input -- comments that are properly sequential versus comments that
overlap -- that determines whether that lack of awareness ever
actually causes a problem.