But if you open the source directory, “every” file is a castle file.

I already know which files are castle files because they’re in the castle directory. It’s redundant information and it makes it hard to browse the files, eg I now need to scroll my file browser in my IDE to the right (so can no longer see directory names), Dane for tab labels snd file path breadcrumbs (on GitHub and in IDE), and on GitHub at least on mobile which is how I viewed it, it cuts the filename off after a certain length.

So I disagree that it’s a meaningless nitpick, it directly affects how easily I can navigate and read the file names. Just because yacc does it too doesn’t make it good (but at least in yacc’s case it’s not redundant information to know they are generated files, unless you put them in a yacc directory)

Have to agree with the OP here.

There may be a handful of yacc files in a large project, so prefixing them with "yy" is convenient to locate them quickly - though I'd still prefer a dedicated subdirectory.

Every file in this project is a "castle file", so preceding every name with "castle" is pretty useless and hinders readability and navigation. If it's not part of castle, it shouldn't be checked into the repo.

And what happens when these castle_xx files have to be combined with files from other libraries?

This goes a long way into avoid namespace conflicts.

Do they need that? If not you’re using a hypothetical situation that likely will never occur to excuse a bad decision (see YAGNI). In my 24 years of programming, I’ve never needed to do this in any way where this naming would have helped me (a very occasional single prefixed file sure, but an entire project, never).