I think we had it this way for the same reason DANDI attaches sub-<subject_id> and ses-<session_id> to the names of files in a dandiset even when they're already nested in folders with that naming pattern; if those files ever get accidentally moved or copied elsewhere, trying to figure out where they belong can be a real pain

Also specific to the nwbconverter.py and behaviorinterface.py, the name of those files is intended to follow the convention where the filename matches the class defined inside, and those classes really ought to be named specific to their experiment type unless they're super general to the lab (in which case they should still be named in a way that makes that clear)

I think we had it this way for the same reason DANDI attaches sub-<subject_id> and ses-<session_id> to the names of files in a dandiset even when they're already nested in folders with that naming pattern; if those files ever get accidentally moved or copied elsewhere, trying to figure out where they belong can be a real pain

That makes some sense for data, where you might imagine the user moving files around, but not really for code. I am not aware of any software libraries that follow this kind of naming convention. Are you?

It's analogous to how DataJoint appends modality identifiers to shared node names across their pipelines: https://github.com/datajoint/element-array-ephys/tree/main/element_array_ephys vs. https://github.com/datajoint/element-calcium-imaging/tree/main/element_calcium_imaging for no_curation, pre_process, and report.

Even though they have the code for each pipeline in a different repo it would be possible for a user/lab to have multiple pipelines nested relatively close together which would produce a structure similar to what we see here

I don't think this is that close. In our case, you have prepended each of the files in a directory with the name of the folder they are contained within. In their case, they have a naming convention for modules that is {modality}_{type}, so there is some commonality among files that have the same modality.

I did not see this before. While doing the current conversion I realized that the past structure I was using is too verbose. I also prefer the more concise standard that Ben is proposing here. The folder structure and class names are enough for disambiguation I feel.

I hear what @CodyCBakerPhD says about having identical files across the repo being more prone to confusion but I also feel that as long as the classes inside are prepend with the name of the conversion like:

{{cookiecutter.conversion_name_camel_case}}BehaviorInterface

It should be all right as no file in the wrong place will run (that said, this structure is still annoying for me in my IDE as makes navigation a bit more difficult but that's probably a problem with my IDE that should have no bearing on the organization of a file system).

Another point that @bendichter has not brought up is that this makes documenting package usage a bit easier when everything inside of each (simple) conversion looks more or less the same and is only the directory / folder that varies for conversion and project.