What you suggest, is a database which is neighter dependable nor verifyable. It's just the usual cobbled together data in another format.
Since the days of BartPE, plugin and script names imply an order, which just does not exist!
It is very common, that not everything needed for modul A, is in a script named modul A. Very often there are bits and pieces also in plugins and scripts, with names, that suggest, that they have absolutely nothing to do with modul A.
I wouldn't waste any time on a project like you suggest. But if you're interested, reading some strings from a script and writing them into some human readable output file, isn't complicated, you could do it in batch.
Actually you seemingly wouldn't waste *any* time with anything, but that's allright.
The issue is not "extracting" the data, it is to "catalog" them and store them in an easily accessible format that can be used to "rebuild" .scripts from the actual database.
Of course some work has to be done with the data, but it is not like re-running dependency walker on every single little app (like if we were starting from ground up).
We have a number of .scripts actually working (though as you pointed out often implemented "badly").
Let's see if I can make an example of the idea (which again I have not been able to find a way to implement).
You have a .script for app "A".
You try it on the LEAST (most minimal you can have) build.
It either works (and then ALL needed dependencies are inside the .script) <- the data you can get from it is OK as is. (it is possible that in the .script there are MORE things than barely needed, but this would be IMHO mostly an exception)
or it doesn't, in which case you put it aside for the moment.
You get another .script and loop through the above, etc.
With a relative simple chore that needs not any particular waste of time and that most members could do (I am thinking of something like a "frozen" project that could run, say, in Qemu) we have a database of "independent" .scripts and one of "not-independent ones".
Then we could tackle one by one the "bad-guys", I am pretty sure that we will soon find "patterns", i.e. "habits" typical of the .script developer or of the Program Author, that may easen fixing the other .scripts from the same developer or the .scripts for other programs by the same Author.
I am not talking of blindly importing all .scripts in the database, I am rather suggesting to find a way to not let the work already done go waste and restart from 0.
If you prefer I am not suggesting that it will be a trifling matter, only that it could be less gargantuan than you seem to think.
Wonko