Sorry, but having a file system in a partition or hidden in a file doesn't make much difference. How would you shrink a file, if the file system in the file is making use of most of the file but there are a hole in the middle of the file system - and hence in the middle of the file?

Your concept would require a lot of file move operations - something that wears down the flash and also may brick your unit or at least lead to file loss in case it runs out of batteries or hangs at the wrong time.

The way you normally do growable file systems on a server is by using a volume manager. A volume manager virtualizes the hardware by using one or more hard disks and splitting into many smaller blocks. A file system is then created from n such blocks. When the file system needs to grow, you pick up a couple of more blocks - from same physical media or on another media and allocates to the file system.

This means that a single HDD can contain multiple partitions and free space. The free space will be allocated as needed without need to shrink any other partition. And if the first disk gets full, you can add a second disk and add to the volume manager - it will then take blocks from the second disk to grow partitions as needed. Because of the virtualization, the file system will not know that some of the data is on one physical disk/memory card and some data on another.

But a volume manager still can't in an easy way perform automatic shrinks, because the blocks that gets added to a partition is not emptied one at a time when you remove files. The file contents are spread out all over the file system. You would need to do something similar to a disk defrag to move the files in the partition into continuous chunks. This can obviously be done, but a battery-operated unit is not a good platform for such a mess.

In the end, you are asking the basic question: "please help me make a mess of my phone so I'm sure I will get a huge nose bleed when I least expect it." You - and a number of other people - are asking for a solution that is worse than the problem you want to solve.

Symlinks allows us to move large files somewhere else and just have a symbolic llink to point from the orignal location to where the data got moved. Yes - you may have to invest a bit of manual labor. But you will not be surprised in the same way, as long as you respect the mount order of partitions and don't move a file that is needed early in the boot process to a partition that gets mounted late.

Allowing files to be added/removed anywhere on the physical media without getting stuck by partition sizes is best handled by a single partition. But a single partition does have other problems. You must decide on a single file system type. And you can't reformat just part of it. And a broken file system will break more of the functionality. And you will require some other mechanisms for quota handling, to make sure that user files doesn't break some system functions by consuming the last of the disk space.