Problems Increasing size of Volume

All volume free space must be contiguous, or together, to be able to expand a volume.

How many volumes are on your disks and what order did you create them?

I see. I have 6. They are not in order.

We do not like moving data around disks, which is why it is not working in your case. You would have to delete the volumes at the end until the area you want to expand is freed up.

I am still in the experimentation phase, exploring so that I know limitations ahead of time.

If I understand correctly, an implication of not moving data around, would be that there is no equivalent to "defragmenting" partitions -- that if I create A, B, delete A, that I cannot "compact" or "defragment" B to the space formerly occupied by A ?

Look at it another way. A RAID 5 volume spreads all data sequentially, in 16K chunks. If you added a disk to the array, either, the new disk is concatenated to the end of the volume (a trick a lot of hardware RAID systems used to do), or if it is correctly incorporated into the volume, then essentially every byte has to be relocated.

Since we have to support any hardware users may use, including low budget USB hardware, poor cables, bad connections, kernel panics, etc, this would have to work flawlessly. A LOT of testing would be required. So yes, it could be done, but the effort is not worth the return at this point. Maybe someday.

Is identity coded as part of the partition, or is it coded in the partition table (or other header space reserved by Softraid) ?

For example if I RAID0 two partitions onto two drives, Partition A drive 1, Partition B drive 1 / Partition A drive 2, Partition B drive 2, and I delete partition A, leaving the drives as [free] drive1, Partition B drive 1 / [free] drive 2, Partition B drive 2. Supposing B is no larger than A was, if I copy Partition B drive 1 to [free] drive 1 using tools outside of softraid (e.g., unmount the RAID and use Carbon Copy Cloner), then if I go to remount the RAID in softraid, will it recognize the cloned area by its data headers (understanding that it might be necessary to remove Partition B drive 1 so as to prevent confusion between two partitions with the same header.) ?

Back when I used SGI's RAID, a volume was a file set, which was an ordered list of "plexes" (that is, logically a file system was the concatenation of the contents of the plexes.) Each plex could have a different RAID configuration, so it was completely valid to have a section of a filesystem that was mirrored between two partitions, and a different section of the same filesystem that was RAID5 between half a dozen partitions. Partitions could be added to or removed from individual plexes without unmounting the file system. It was a recognized (and recommended) strategy to migrate a filesystem to different drives by adding partitions as mirrors to existing plexes, letting the plex synchronize, and then removing the old partition from the plex. Filesystems could be grown by creating an additional plex and adding it to the end of the volume and then telling the OS to grow the filesystem. Shrinking a filesystem was also possible, but was more difficult due to the need to ensure that no part of the plex was in active use in the filesystem.

The behaviour of softraid, where I have to unmount all the filesystems on a given drive before a volume can be added or removed would not have been acceptable for business use. I can get away with it on my own system because it is one-user... well, except when I am running a longer computation...

You were dealing with enterprise RAID hardware, based on your wording.

You cannot do this with macOS, because "partition maps with mounted volumes are write protected".

That was a basic hard coded law in Mac OS 10.2 onwards.

However, with Boot Camp, Apple added some proprietary mechanism to "soft partition" new partition maps, then write out the new partition maps at shutdown/restart. that is how they added boot camp to a live system.

We do not have access to this partition map protection bypass.

"The behaviour of softraid, where I have to unmount all the filesystems on a given drive before a volume can be added or removed would not have been acceptable for business use.

For example I started a multi-hour file restore. A while later I thought I should create a new partition and install some software onto it. But I can't, because creating a new managed partition requires unmounting everything, including the filesystem that the the long file restore is happening to...

Perhaps with APFS SoftRAID volumes in the future you will be able to do this. With HFS it is an absolute rule for user security, and we follow all Apple Security guidelines. (Disk Utilty does not follow Security guidelines, it runs as root, and can do things like delete volumes without a password)