Evaluate install script structure ahead of Pod 6 — split per-variant vs extend pod/capabilities

[ng]

Context

scripts/install is a single ~1500-line script today, branching on pod variant via scripts/pod/detect and scripts/pod/capabilities. Pod 3 has its own install path; Pod 4 is the working baseline; Pod 5 diverges on tmpfs/RAW handling; Pod 6 is on the horizon.

Question

As variant count grows, should the install script:

1. Stay monolithic — keep one file, push more divergence into pod/capabilities flags?
2. Split per variant — scripts/install-pod3, install-pod4, etc., each ~200-400 lines?
3. Hybrid — shared scripts/lib/install-common, thin per-variant entry points?

Initial read

Lean (1) for now. The existing pod/detect + pod/capabilities pattern is the right primitive — variants should be expressed as capability flags, not branching at the script level. A real split makes sense only when one variant diverges on >40-50% of install steps. Today Pod 3's deviations are small enough that capability flags handle it cleanly.

Re-evaluate when Pod 6 work starts and we know what fraction of its install is genuinely new vs shared.

Decision criteria to apply when Pod 6 lands

• How many install steps are Pod 6-specific (% of total)?
• Are any shared steps subtly different on Pod 6 (timing, ordering, paths) in ways that would force if pod6 branches inside otherwise-shared blocks?
• Does Pod 6 introduce new systemd units / services that don't exist on older variants?

If >40% divergence or systemd-unit-level differences → option (3).
If mostly capability flags → option (1).

Out of scope

PR #600 (deviceinfo perms fix). Recording this for follow-up.