Individual / self-serve
1. Hobbyist signs up, creates one tenant — the baseline; everything settled already covers it.
2. Freelancer with several client projects — is that N tenants or one tenant with paths? First real test of "what deserves a tenant boundary."
3. User hits their tenant cap — what they see, how they ask for more; the entitlement story's front door.

Teams / companies
4. Founder creates tenant, invites team, promotes a co-owner — multi-owner, last-owner invariant in daily use.
5. Founder quits or is fired — ownership transfer + credential revocation (sessions, tokens) in one motion.
6. Company acquired — tenant changes hands wholesale; interacts with immutable slugs.
7. Two companies collaborate on a project — guest members vs. a shared/linked tenant; cross-tenant boundary crossing.

Service providers
8. MSP, 150 employees, provisions client tenants — firm-level ownership, the branch that forced hierarchy.
9. Client fires the MSP and keeps their tenant — custodian vs. beneficiary; who can eject whom.
10. Reseller onboards a customer who has no user account yet — invitation-shaped provisioning, tenants in limbo pending acceptance.
11. Agency builds, then hands off completely — one-time transfer, no standing relationship afterward.

Automation
12. Developer's CLI scripts create/destroy dev-and-test tenants daily — parity, plus: does quota count live tenants or lifetime creations? Churn makes those very different.
13. An application built on atlas9 provisions a tenant per end-customer signup — the platform itself as the MSP; whose quota, whose anchor?

Abuse / lifecycle / operations
14. Spammer scripts signup → tenant → invitation emails — the full anchor chain under attack.
15. Sole owner deletes their account (or dies, or just vanishes) — the invariant under deletion: block, force-transfer, or orphan-with-cleanup.
16. Abuse report arrives — operator asks "who owns this?"; suspension semantics: tenant, owner, or both.
17. Support/admin creates a tenant to reproduce a bug, or bulk-imports tenants from a legacy system — the below-the-public-API creation path.

Worth noticing: 1–7 are all satisfied by the flat settled design; 8–13 are the ones that pry open the owner-as-entity and quota-semantics branches; 14–17 mostly test invariants and operator tooling rather than ownership shape. If any deserve a deeper walk, 12 and 13 are the sneaky ones — automation churn and platform-on-platform tend to break assumptions that the human-shaped cases never touch.