But If It's easier, I wouldn't mind sticking to only considering tracked files at HEAD and adopting the GitHub Linguist approach entirely.

I'd like that, i.e. dropping the index approach which I'd find quite uncommon. Either everything in the worktree, sans .gitignored files, or everything in Git, but not a mix of that by considering the staging area. The difference of the staging area and the worktree probably also isn't big enough to warrant that.

Specifically, how the list of files and their contents would be different between the two. Would it be that reading from the index would implicitly use git built-in behavior (like .gitignore) instead of needing to explicitly do that e.g. via the ignore crate?

The index is a tree of a commit, and staged changes. This does indeed imply that .gitignored files aren't in there, as they are (typically) not added.

Ah, I see, thanks!

Your response reminded me of something I'd like to raise this for consideration:
In a dotfiles repository, it's not uncommon to ignore everything and add files with git add -f (this is what I do).

# .gitignore
*

This makes it harder to accidentally stage sensitive files and cleans up the git status output.
So, for certain repositories, reading the .gitignore might ignore too much.

Just checking: are we good to move forward with reading from HEAD?

Yes, sounds good to me