But they always support extending to the right, never directly to the left.
Presumably you are referring to HDD/SSD representations that use a linear array of sectors or logical blocks.
The left-most sector/block would have (absolute) Logical Block Address (LBA) of 0.
The right-most sector/block would be the end of the drive, and have the largest LBA.
Note that the LBA is typically represented by an unsigned 48-bit integer in the ATA interface.
Extending to the left is done by copying the partition left (byte for byte in a lot of cases) and then extending right.
That's not an accurate description.
Rather than "copying" the partition, the partition is relocated by moving it, sector/block by sector/block (not "byte for byte").
Is it not as simple as changing the partition boundary, then moving/updating the inode tables?
Obviously not, since that operation is never offered.
The partition is merely a defined container for a filesystem.
The partition is physically defined in terms of a starting LBA, an ending LBA, and the number of sectors/blocks.
Other attributes of a partition are irrelevant to this discussion.
The filesystem defined for the partition will use LBAs relative to the start of the partition.
The filesystem does not care nor is it aware of the position of its partition on the HDD/SSD.
The filesystem is only aware of LBAs starting at 0 (the start of its partition) through the LBA corresponding to the end of the partition.
By using relative addressing the filesystem is inhibited (and therefore guaranteed) from accessing any sector/block outside its partition.
If "changing the partition boundary" means redefining the start of the partition without moving the filesystem to the new start of the partition, then that creates unsolvable scenarios.
If you tried to use the existing LBAs, then the new partition area would have LBAs that are less than zero, which cannot be represented with unsigned integers. So there is no way to address the newly created area to the "left" of the original partition.
If you try to recalculate every LBA stored in the filesystem to its new relative value, then you're trying to solve a near-impossible task to find every LBA in the filesystem. Overlook any LBAs, and you are assured of eventual filesystem corruption.
Even if you're successful in updating every LBA, the filesystem could then appear to be corrupted because there are usually specific filesystem entities that need to be located at specific (relative) LBAs. But the "changing of the partition boundary" has altered the locations of those entities that should be at fixed (relative to the partition start) LBAs.
Bottom line, the start of the partition and the position of the filesytem within that partition has to be kept consistent.
