diff --git a/future-plans.md b/future-plans.md
index dd56c36..3f268bf 100644
--- a/future-plans.md
+++ b/future-plans.md
@@ -215,6 +215,34 @@ Key design points:
 - A storage grid can have multiple view layers (e.g. lid photo, tray photo, labeled
   overlay)
 
+### Irregular grid layouts and merged cells
+Real storage boxes rarely have perfectly uniform grids. Two distinct physical
+configurations need to be supported:
+
+**Type A — uniform grid with merged cells:** A regular N×M grid where some adjacent
+cells are physically merged into one larger cell (always an integer multiple of the
+base cell size). Common in component assortment boxes. A merged cell is both a
+physical and logical unit — you store one thing in it.
+
+**Type B — stacked sub-grids:** A container where each row (or section) has a
+different column count and cell size. Example: 5 rows of 5 small columns, then 1
+row of 4 medium columns, then 1 row with a single large drawer. Cells are not
+multiples of a common base — the sections are structurally independent.
+
+**Logical merging (multi-select):** Independent of the above, a user should be able
+to designate several cells as one logical storage location (e.g. a large component
+that physically spans 3 cells). This is a storage/inventory concern rather than a
+grid layout concern.
+
+**Open question — architecture:** Should this be:
+1. A single generic nested/hierarchical grid model flexible enough to encode both
+   types (more complex but unified), or
+2. Two explicit grid styles (`uniform+merges` and `stacked-sections`) that cover
+   the common cases without a fully general solution?
+
+Option 2 is likely sufficient for real-world boxes and much easier to implement and
+display. Worth prototyping before committing to a generic model.
+
 ### Multi-cell grid storage selection
 A component stored in a grid should be able to span multiple cells, since larger
 parts often occupy more than one cell. The graphical cell picker in the inventory