Not exaclty sure what you are trying to do. Are you saying that you have so many additional files in the package that you would like to import them from a list, like a directory listing?
The issue is really two fold.
First, once you have set up a list of additional files, the management console does not seem to scroll far enough to the right to see the file names at the end of the path. Being able to do an export, if it were a text file, would be a way to see what additional files are being used in a package and could also be imported into documentation.
The 2nd issue is that I have a package that has a large number of additional files. For this deployment I first have to run an uninstall of the old version of the program. The install package with all the additional files takes a long time to copy all the files, leaving the user without this application for an extended period of time. If I could build the uninstall package to include the list of additional files I may be able to improve the user experience by having all the files present before running the uninstall, thus reducing the time the user is without the application. Being able to export the file list, then import into another package would greatly improve this process. In this specific case I used the auto detect to create the additional files list, because I can't see the file names I can't identify what files are needed and manually add the same list of files to another package.
On the first issue, we long ago gave up trying to package up applications with large numbers of files. We just zip them up into a self-extracting .exe. The client is much more efficient at downloading a single large file than multiple small files.
On the second point, I would create two jobs. The first job would contain a self-extracting .exe that has the files for both the old and the new application. Extract these to some tempory folder, then write a key to the registry that these files were successfully copied to the machine. You can pull this registry key into inventory to find the machines that are ready to upgrade. This can all be done silently, without the user even knowing. The second job would they prompt the user to upgrade and run a scipt to uninstall the old application and install the new one.
"...because I can't see the file names I can't identify what files are needed and manually add the same list of files to another package."
It sounds like you inhehited a package that someone else created and can't see what files were used because of limitations in the interface. I would go into SQL and pull out the list. I don't know the table name off the top of my head, but it should not be too difficult to figure out. From this point on, I would start zipping the files up. It makes it way easier to manage your package library.
I second the use of 7-Zip to create self extracting files, we use it on our Office 2010 (still in pilot) deployment and it saves a lot of time in copying files.
We learned the hard way, that in Win 7 you cannot extract to the sdmcache folder.... so we use %WINDIR%\TEMP\some_folder_name
Also learned that %TEMP% gets tricky in testing, if you launch a bat file, etc for testing logged it, %TEMP" will patch to the logged in user.... so to keep it simple we call %WINDIR%\TEMP