diff --git a/RAISING-PLAYER-CAP.md b/RAISING-PLAYER-CAP.md
index 60b79cce..dd4c2f5d 100644
--- a/RAISING-PLAYER-CAP.md
+++ b/RAISING-PLAYER-CAP.md
@@ -21,7 +21,7 @@ see "Why 31, not 32" below.
 | Hard ceiling if you also widen one serialized field | 255 (engine arrays are sized 255) |
 | Is 16 an engine limit? | **No.** It is a set of independent constants and one 5-bit field |
 | Biggest *code* task | CTCL roster arrays + lobby UI layout |
-| Biggest *non-code* task | **Per-map drop zones** ? most maps only define ~16 |
+| Biggest *non-code* task | Lobby pod-grid / scoreboard layout. Drop zones are **not** a blocker ? see Layer 7 |
 | Does netcode bandwidth block it? | Almost certainly not on modern hardware; verify, don't assume |
 
 ---
@@ -171,16 +171,25 @@ teams is beyond the 4-bit `m_teamCount` limit of 15, so they are fine.
 These are cosmetic and non-blocking: 31 players can connect, spawn and play with an ugly
 scoreboard. Defer.
 
-### Layer 7 ? Map content (**the true gating task**)
+### Layer 7 ? Map content (drop zones: a polish item, NOT a blocker)
 
-Every MP map used at high player counts must define **¡Ã N drop zones / start points**. Most stock
-maps define ~16. Players beyond the available start points **silently fail to spawn** ? no error.
+Most stock maps define ~16 drop zones / start points.
 
-This is per-map authoring work in the mission editor (`Gameleap\mw4\run-editor.bat`), completely
-independent of the code changes, and it is the item most likely to dominate the schedule.
+**This was previously assumed to be the gating task. It is not.** Verified empirically on real
+pods: when there are more 'Mechs than drop zones, the surplus 'Mechs **spawn on top of each
+other**. They clip and collide for a moment, take some minor damage, then separate and play
+normally. It resolves itself within seconds.
 
-Audit approach: enumerate drop zones per map, produce a table of map ¡æ start-point count, and
-decide which maps are certified for 31-player play.
+So a drop-zone shortfall is a **quality-of-experience issue, not a functional failure**. It does
+not block raising the cap, and it should not gate the schedule.
+
+Worth doing eventually for the maps that see the most high-count play ? an overlapping spawn is
+untidy and hands out free chip damage ? but it can happen any time, before or after the code work,
+and it never needs to be complete.
+
+Audit approach if/when you want it: enumerate drop zones per map, produce a map ¡æ start-point
+count table, and add start points to the busiest maps first in the mission editor
+(`Gameleap\mw4\run-editor.bat`).
 
 ### Layer 8 ? Network performance (verify, don't assume)
 
@@ -201,18 +210,19 @@ design suggests none exist, but grep for it.
    add the missing bounds check in `CTCL_AddPlayer`. Nothing else is safe until this is done.
 3. **Layer 2** ? raise the compiled defaults. Rebuild `MW4.exe` (Release + Profile).
 4. **Layer 4** ? decide and implement the bot cap.
-5. **Layer 7** ? audit maps for drop zones; author more on the maps you care about. Runs in
-   parallel with everything else and will take the longest.
-6. **Layer 5** ? lobby UI rework (roster rows, pod grid, launch guard).
-7. **Layer 6** ? scoreboard/radar/review polish.
-8. **Layer 8** ? one live load test.
+5. **Layer 5** ? lobby UI rework (roster rows, pod grid, launch guard).
+6. **Layer 6** ? scoreboard/radar/review polish.
+7. **Layer 8** ? one live load test.
+8. **Layer 7** ? optional: add drop zones to the busiest maps. Non-blocking; surplus 'Mechs
+   already spawn stacked and separate on their own.
 
 ## Verification checklist
 
 - [ ] Rebuild clean (0 errors) in Release and Profile
 - [ ] Host a game; lobby shows the new slot count and the launch guard accepts it
 - [ ] Player N connects (watch `Environment.NetworkMaxPlayers` ¡æ DirectPlay `dwMaxPlayers`)
-- [ ] All N players actually **spawn** on a map with ¡Ã N drop zones (this is where it will fail)
+- [ ] All N players actually **spawn** (surplus 'Mechs stacking on shared drop zones is expected
+      and self-correcting ? not a failure)
 - [ ] Cameraship still connects on top of the pilot cap (regression from the 2026-07-24 fix)
 - [ ] Bots fill correctly to the intended bot cap, and `g_nBOTs` matches connected lancemates
       (mismatch = silent infinite "loading", the classic failure mode)
@@ -230,6 +240,7 @@ design suggests none exist, but grep for it.
   `nLaunchState = 3` forever because `CTCL_CheckServerReady` never sees
   `nCount == g_nTeslas + 1` and matching lancemates. If you see that, suspect a count mismatch,
   not a crash.
-- **Drop-zone shortfall produces no error** ? just missing players.
+- **Drop-zone shortfall is benign** ? surplus 'Mechs spawn stacked, bump, take minor damage and
+  separate. Do not mistake this for a bug, and do not let it gate the work.
 - **Writing 32 into a 5-bit field truncates to 0**, which will look like "max players became
   unlimited/zero" rather than an overflow.