After #578 fixes editing column names in the presence of hidden columns, there's a funny edge case that results:

• Make three columns (with different second row names so we don't hit Column is automatically merged when merge_duplicate_headers = true if the names are the same and the data is different #490 😏) with first-row names A, B, A
• Hide B -> now the first row headers merge into a single A
• Rename A to C
• Only the first column changes to C; the other one is still A, so they cease to be merged. This is because when renaming we consider all the columns, not just the visible ones, and in that context these cells actually aren't merged.

From one perspective this is a bug: you started with a single header and you edited it, that name should apply to everything the original one applied to. Note that if the hidden column was also named A, all three of them would have been renamed to C, so the editing action depends on invisible properties.

From another perspective, the full table is the authority, and if it doesn't consider the first and third column headers to be merged then why should the edit operation? If we take that perspective, perhaps the real bug is that the two As merged into one header in the first place. They're not adjacent in the full table, so they should not be considered mergeable, regardless of whether the column between them is visible.