Problem statement
Design the object model and public APIs for an in-memory key-value store whose distinguishing feature is transactions: a caller can open a transaction, make a batch of edits that stay invisible to everyone else, and then either commit them atomically or roll them all back. Transactions must nest — opening a transaction while one is already open stacks a new scope on top, and commit/rollback affect only the innermost scope. This is the storage kernel a shell (REPL) or a command dispatcher would drive, not the shell itself.
Operating context. A single in-process library holding string keys mapped to values. Outside any transaction, set/delete mutate the committed store directly and are immediately visible. Inside a transaction, the same operations are staged in that scope's write buffer; a get must read the innermost scope that has touched the key, falling back through the enclosing scopes to the committed store. commit merges the innermost scope's staged writes into its parent (or into the committed store if it is the outermost), while rollback discards them; both then pop the scope. A deletion inside a transaction must shadow an existing committed value (a read sees "absent", not the old value) yet be undoable on rollback. Assume one caller on one thread drives the store, but the concurrency model is a design question you must address, not ignore.
Out of scope. The REPL / command parser and its I/O, on-disk persistence or a write-ahead log, network access and any client/server protocol, key expiry / eviction / memory limits, and range or prefix scans over keys. Design the in-process object graph and its transaction semantics, not the process around it.
What to produce. The class hierarchy (the store facade, a transaction / scope abstraction, the per-scope write buffer, and the value + tombstone representation), the public API each class exposes, and the state transitions of a transaction scope (open -> committed / rolled-back). Be explicit about: how a stacked scope isolates uncommitted writes and how a get resolves through the scope stack; how a deletion is represented so that "deleted here" is distinguishable from "never set here"; how commit folds one scope into its parent and how rollback undoes staged edits; what data structure records the undo information; how you would make the store thread-safe if multiple callers arrived (locking granularity, and what get sees mid-transaction); and how the design stays open to a primitive that fails a commit if a watched key changed underneath it, without rewriting the transaction core.