theoretical you could have added one more file to the filegroup and used
DBCC SHRINKFILE (N'<original file>' , EMPTYFILE)
to move all data into the new files (will be evenly distributed in this case.
Drawback: it can take VERY long when it is a big file / filegroup and even in I read somewhere, that I could cancel / kill the DBCC-session, it seems to rollback the whole move sometimes (at least on SQL 2016).
Benefit: usually your original file is e.g. 400 GB (current size) but you do not want to have four 400 GB files that are filled only to 25 % (I guess everyone favors four 100 GB files). When you just rebuild Indexes (or even create copies of the tables and move data into them, e.g. because you want to add partitioning), you will end with 400 GB + 100 GB + 100 GB + 100 GB, where about 4/7 of the data remains in the first file and 1/7 in each of the three new files (because it redistributes it depending on the free space in a file).
If you would add four 400 GB files and rebuild indexes etc., the data would be distributed equally and you can (usually) shrink the three new files to 100 GB using the TRUNCATEONLY option for DBCC SHRINKFILE, but not the original file, since there is a high chance, that even some pages in the last 100 GB of the file are or were in use.
But when you add four complete new files, you could just delete the clumsy old one after the EMPTYFILE...
God is real, unless declared integer.