Unfortunately, we can't do that right now. The closest thing to this kind of functionality is the file placement balancing system. I call it a system because it exists in both the user service and the kernel code, the 2 pieces have different tasks. The kernel code is responsible for new file placement in real-time and the service code re-balances existing files. Because the kernel code runs in real-time, the service code has no need to run periodically. But it can be triggered by certain conditions such as a file placement rule change, a file move which violates existing rules, etc... Not needing periodic balancing in the background is obviously desirable because it scales well, so I tried to minimize that as much as possible.
Sorting by name is conceptually similar to sorting by size (in that you are sorting by some attribute of the file itself). But it has one crucial difference.
For pattern based file placement, the kernel component that makes the decision which disk a new pooled file should be placed on can look at the file name at creation time and make that decision in real-time with no post-processing required by the background service.
If we want to do the same thing but based on file size, well that's a problem. The file size is completely unknown at file creation time. When a new file is created, typically, the OS gives us absolutely no information about how large that file is supposed to be. That option is there, but it's seldom used by anyone. So practically, there is no way to know which disk a new pooled file should be placed on, if we want to sort by file size.
We can add this, but enabling it would mean periodic balancing runs. I suppose that may be ok for some use cases.