Exercise 1: Tracing Both Dedupe Functions on ["b","a","b","c","a"] — Possible Solution
====================================================================

TRACING dedupe_ordered (INTERPRETATION B) BY HAND
------------------------------
seen = {}, result = []

  x="b": not in seen -> add "b" to seen, append "b" to result
         seen={"b"}, result=["b"]
  x="a": not in seen -> add "a" to seen, append "a" to result
         seen={"b","a"}, result=["b","a"]
  x="b": already in seen -> skip
  x="c": not in seen -> add "c" to seen, append "c" to result
         seen={"b","a","c"}, result=["b","a","c"]
  x="a": already in seen -> skip

Final result: ["b", "a", "c"] - deterministic, always the same on every
run, because it only depends on the order the input list is walked in.

TRACING dedupe_set (INTERPRETATION A) BY HAND
------------------------------
This one is different in an important way: list(set(lst)) depends on
the internal iteration order of a Python set, which is based on each
element's hash value and the set's internal table layout - NOT on
insertion order. Running list(set(["b","a","b","c","a"])) three times
in separate Python processes actually produced three different-looking
results: ["a","c","b"], ["b","a","c"], and ["a","c","b"] again. This
is because Python randomizes string hashes by default in each new
process (a security measure, PYTHONHASHSEED), so the "same" call to
dedupe_set on the "same" input can legitimately produce a different
order each time the program runs.

THE PSEUDOCODE FIX
------------------------------
One precise sentence that would have forced an unambiguous choice from
the start:

    "Remove duplicate elements from the list, keeping only the first
    occurrence of each value and preserving the original relative
    order of the remaining elements."

This single sentence rules out the set-based interpretation entirely,
since it explicitly names both requirements (first occurrence, original
order) that the vague version left unstated.

WHY THIS WORKS AS AN ANSWER
------------------------------
The trace correctly derives dedupe_ordered's deterministic result step
by step, and goes further than simply stating dedupe_set's result by
actually confirming (empirically, across repeated runs) that the
set-based version isn't just "a different valid answer" - it's
genuinely non-deterministic, which is an even stronger argument for why
the original vague spec was inadequate. The proposed pseudocode
sentence directly addresses both missing requirements (which occurrence
to keep, and whether order matters) rather than only one of them.