This is an issue of inodes, a feature mainly in Unix filesystems (like ext4) which is a fixed-size table storing metadata of all files on the partition. When the partition is created, a fixed number of inodes is created.

On my 500GB drive using the default ext4 from Ubuntu, I have 27 million inodes (this can be checked using df -i if you're on Linux), many times more than the number of Bitcoin blocks in the blockchain. Thus I don't run into this issue, and I imagine most people don't - it's possibly something to do with the specific filesystem/setup you're using.

ext4 specifically doesn't have a cap on the number of files in a directory, so splitting the files into multiple directories would be unlikely to help. FAT32 however has a limit of 65,534 files per directory, the solution there is not to use an outdated filesystem like FAT32.

Generally there are two ways to approach this sort of issue:

1. Increase the resource (make more inodes)

This can be done by specifying a larger number of inodes when creating the partition, which is relatively easy to do (example) but requires foresight that you're going to be running a node on the partition. Alternatively, make another partition with the required number of inodes.

2. Use the resource more efficiently (use fewer inodes).

Perhaps the simplest way to achieve this is to just stick multiple blocks in a file - I'm not sure how this would work from an architectural point of view but it's something that would have to be implemented in the client.