Nice contribution, @jensenpat — this is a real usability improvement. The approach is clean: early guard in the layout picker, pre-flight check in applyPanLayout, and a fallback in createPansSequentially when the radio itself rejects the request. A few observations:

Looks good

• Extracting panCountForLayoutId() to deduplicate the map is a nice cleanup.
• The 4-second timeout matches existing capacity-limit messages (panadapterLimitReached, sliceCreateFailed both use 4000 ms), so this is consistent.
• showPanadapterSliceCapacityMessage() correctly handles the model().isEmpty() edge case.
• Files changed are strictly in scope — just MainWindow .cpp/.h.

One concern: early guard in eventFilter may block valid layout downsizes

In the eventFilter hunk (around the m_addPanLabel click handler), the new guard is:

if (requestedPanCount > activePanCount
        && currentSliceCount >= m_radioModel.maxSlices()) {
    showPanadapterSliceCapacityMessage();
    return true;  // <-- blocks before saving the layout choice
}

This correctly allows downsizing (e.g. 4→2 pans when at capacity). However, consider this edge case: if the user picks the same layout they already have (e.g. re-selecting "2v" when they already have 2 pans and are at slice capacity), requestedPanCount == activePanCount so it falls through and calls applyPanLayout → which is a no-op anyway since needed == existing. That's fine, just noting it's harmless rather than a bug.

Minor: applyPanLayout guard returns early after showing the message, but the layout setting was already saved by the caller

Looking at the flow: the eventFilter saves the layout to AppSettings before calling applyPanLayout. If the early guard in eventFilter fires, it returns before saving — good. But if the guard in eventFilter passes (e.g. user was at maxSlices - 1 when they clicked but another Multi-Flex client created a slice in the meantime), then the layout is saved to AppSettings, then applyPanLayout hits its own guard and returns early. On next launch the saved layout won't match the actual pan count. This is a narrow race but worth noting — the existing code has the same pattern for other failures in applyPanLayout, so this isn't a regression.

Suggestion for a follow-up (not blocking)

The existing sliceCreateFailed signal handler (line ~1528) already shows a similar message. When createPansSequentially fails and calls showPanadapterSliceCapacityMessage(), the radio's error response may also trigger sliceCreateFailed, potentially showing two overlapping status-bar messages. Since showMessage replaces the previous one this is cosmetic at worst, but you could consider either deduplicating or suppressing one path. No need to address in this PR.

Overall this is a solid, well-scoped change. Thanks for the contribution!