(No comment was entered for this change.)

IMHO, it would be good to re-use the "tags" pane for this purpose -- files as part of the project would simply 
be one level higher in the hierarchy than chapter/section/etc.

Files in a project are not always one level higher than the actual sectioning tree.
Sometimes whole parts and chapters are located in their own file.
The sectioning tree available through the "tags" may be built taking \include commands into account
and add the tags of included files.

If we implement project support, I think we should do it on a larger scale. There is
one problem, though, that is independent of whether we do full-scale project support
or just enhance the abilities of the tags panel:

\includes can be nested in a pretty arbitrary way, AFAIK. So you could have the case,
e.g., where one file is included several times in another file. To make matters
worse, I'm pretty sure that you can even conditionally include files. This would
require completely parsing the *TeX code, which is out of the option.

But then again, all this could be considered unnecessary altogether, with the
rationale that it's the fault of everyone who uses such complex inclusion schemes.

Does anyone have any ideas about this?

Although it's possible, it's not probable that one file will be included multiple times; and even if it is, it certainly 
(hopefully) won't recursively include itself. I'd definitely only target the simple case of one master file with at 
most a couple of nested levels of inputted/included files. (Consider that books and theses will usually only 
consist of separate files per-chapter.)

I have to admit it's hard for me to imagine if combining the tags panel with a "project files" panel would actually 
work in practise, but if you're going for a lightweight interface I think it would be worth investigating. A full-
blown files pane such as in TextMate or BBEdit would be overkill IMO. But I could be wrong.