Originally brought up in #102 (comment) and discussed briefly in the https://github.com/bids-standard/bids-specification/pull/946/files#r771841807 with @Lestropie.

The Inheritance Principle (IP) has

2. For a given data file, any metadata file is applicable to that data file if:
...
c.The metadata filename does not include any entity absent from the data filename.
...
4. There MUST NOT be multiple metadata files applicable to a data file at one level of the directory hierarchy.

from which for IMHO a legit (didn't check with bids-validator though) case of

├─ sub-01/
│  └─ func/
│     ├─ sub-01_task-rest_acq-tricky_bold.nii.gz 
│     ├─ sub-01_task-rest_acq-tricky_bold.json
│     ├─ sub-01_task-rest_bold.nii.gz 
│     ├─ sub-01_task-rest_bold.json

we would get a violation of the rule 4 if we follow 2.c
since both sub-01_task-rest_bold.json and sub-01_task-rest_acq-tricky_bold.json would be applicable to sub-01_task-rest_acq-tricky_bold.nii.gz .

I see following possible Fixes:

• F1: do declare such cases/datasets "non-legit" due to inheritance principle (bids-validator should catch that then)
• adjust inheritance principle to make such conflicts avoidable. Possible way I see:
  • F2: Add clarification to 4 (e.g. 4.a) that "- metadata files at the level of the data file and matching data file exactly in all entities and suffix, but only different in extension, are not to be considered as metadata files for other data files" . I.e in the example above sub-01_task-rest_bold.json is not considered for sub-01_task-rest_acq-tricky_bold.nii.gz since there is sub-01_task-rest_bold.nii.gz.
    • cons: implementation might be tricky since we do not per se have "data suffix" since there could be multitude. So the simplest implementation would be "test if there is ANY other file without such (.json) extension". Then there would be another separate validation check if that other file is part of BIDS according to the schema.
• Contribute more!