This is a great point -- but for users who don't know what they're doing, it's because they don't understand the meaning of the word in Unity's context. A better description of what Unity means when it says "dependencies" would go a LONG way, so when their stuff actually _is_ likely to have dependencies, the user will know, and can be prompted on how to address this. In general, a user knows when a script is always a script or an asset is always an asset -- but an fbx might need materials/etc. (though not always, and not for all .fbx files), and in the case where they do, why not just let the user manually flag the ones that _might_ have dependencies upon importing them into the project (and let the Unity handle the ones that definitely do, unless the user chooses to override them and link them to something else -- say, an .fbx to a different texture than the one in his model file). The user could also do this later when modifying the file (or any newly-made dependencies -- i.e. when you create a new texture in Unity that should be available to different models or scripts/shaders, you should be able to mark that script's list of dependencies i.e. via drag/drop). Then we would ultimately save the resulting information / flags to a very simple list/database/asset, and therefore save users the dependency scan altogether. For a less complex solution, why not simply give the user a button or a menu popup that lets the user choose to check certain assets based on filetype (i.e. like fbx files) who are known to typically contain dependencies, and rather than go file-by-file, let these users choose to go filetype by filetype, masking off any filetypes they don't want Unity to check for dependencies. Even doing everything the current way, it would likely still be faster with this kind of masking. The user knows which filetypes he/she has in his/her project, and this special knowledge could easily help Unity _semi-automatically_ help the user.