[FIX] add paragraph on MEG specific "markers" suffix in MEG spec

src/04-modality-specific-files/02-magnetoencephalography.md

@@ -36,27 +36,36 @@ without the need to parse files in proprietary data format. Other relevant files
 MAY be included alongside the MEG data; examples are provided below.
 
 This template is for MEG data of any kind, including but not limited to
-task-based, resting-state, and noise recordings. If multiple Tasks were
-performed within a single Run, the task description can be set to
-`task-multitask`. The \_meg.json SHOULD contain details on the Tasks.
+task-based, resting-state, and noise recordings.
+If multiple *Tasks* were performed within a single *Run*,
+the task description can be set to `task-multitask`.
+The `*_meg.json` file SHOULD contain details on the *Tasks*.
 
 Some manufacturers' data storage conventions use folders which contain data
-files of various nature: for example, CTF's `.ds` format, or BTi/4D.
+files of various nature: for example, CTF's `.ds` format, or BTi/4D's data folder.
 Yet other manufacturers split their files once they exceed a certain size
-limit. For example Neuromag/Elekta/Megin, which can produce several files
-for a single recording. Both `some_file.fif` and `some_file-1.fif` would
-belong to a single recording. In BIDS, the [`split`](../99-appendices/09-entities.md#split) entity is RECOMMENDED to
-deal with split files.
-Please refer to [Appendix VI](../99-appendices/06-meg-file-formats.md) for
-general information on how to deal with such manufacturer specifics and to see
-more examples.
-
-The [`proc-<label>`](../99-appendices/09-entities.md#proc) entity is analogous to [`rec-<label>`](../99-appendices/09-entities.md#proc) for MR and denotes a variant of a file
-that was a result of particular processing performed on the device. This is
-useful for files produced in particular by Elekta’s MaxFilter (for example, sss, tsss,
-trans, quat, mc), which some installations impose to be run on raw data
-because of active shielding software corrections before the MEG data can
-actually be exploited.
+limit.
+For example Neuromag/Elekta/Megin, which can produce several files
+for a single recording.
+Both `some_file.fif` and `some_file-1.fif` would belong to a single recording.
+In BIDS, the [`split`](../99-appendices/09-entities.md#split) entity is RECOMMENDED to deal with split files.
+
+Another manufacturer-specific detail pertains to the KIT/Yokogawa/Ricoh sytem,
+which saves the MEG sensor coil positions in a separate file with two possible filename extensions  (`.sqd`, `.mrk`).
+For these files, the `markers` suffix MUST be used.
+For example: `sub-01_task-nback_markers.sqd`
+
+Please refer to [Appendix VI](../99-appendices/06-meg-file-formats.md)
+for general information on how to deal with such manufacturer specifics and to see more examples.
+
+The [`proc-<label>`](../99-appendices/09-entities.md#proc) entity is analogous to the
+[`rec-<label>`](../99-appendices/09-entities.md#rec) entity for MRI,
+and denotes a variant of a file that was a result of particular processing performed on the device.
+This is useful for files produced in particular by Elekta's MaxFilter
+(for example, sss, tsss, trans, quat, mc),
+which some installations impose to be run on raw data prior to analysis.
+Such processing steps are needed for example because of active shielding software corrections
+that have to be performed to before the MEG data can actually be exploited.
 
 ### Recording EEG simultaneously with MEG
 

src/99-appendices/06-meg-file-formats.md

@@ -231,11 +231,11 @@ More about the 4D neuroimaging/BTi data organization at:
 
 ## KIT/Yokogawa/Ricoh
 
-Each experimental run on a KIT/Yokogawa/Ricoh system yields a raw
-(`.sqd`, `.con`) file with its associated marker coil file(s) (`.sqd`, `.mrk`),
-which contains coil positions in the acquisition system’s native space.
-Head points and marker points in head space are acquired using third-party
-hardware.
+Each experimental run on a KIT/Yokogawa/Ricoh system yields a raw file with either
+`.sqd` or `.con` extension,
+and with its associated marker coil file(s) with either `.sqd` or `.mrk` extension.
+The marker coil file(s) contain coil positions in the *acquisition system's native space*.
+Head points and marker points in *head space* are acquired using third-party hardware.
 
 Example:
 
@@ -253,7 +253,18 @@ sub-control01/
             sub-control01_ses-001_task-rest_run-01_meg.<con,sqd>
 ```
 
-If there are files with multiple marker coils, the marker files must have the
+To understand why both `.sqd` and `.con`, as well as both `.sqd` and `.mrk` are valid
+extensions, we provide a brief historical perspective on the evolution of the data format:
+The original extension for KIT/Yokogawa/Ricoh continuous data was `.sqd`.
+This was later modernized to `.con` (to denote "continuous").
+However, to preserve backwards compatibility, `.sqd` is still a valid extension for the raw, continuous data file.
+The original extension for KIT/Yokogawa/Ricoh marker files was `.sqd` as well.
+That lead to the ambiguous situation where both the raw data and the marker file(s) could end on `.sqd`.
+To distinguish between continuous data and marker file(s), the internal header of the files needed to be read first.
+For this reason, the marker file extension was later modernized to `.mrk` to better disambiguate files.
+However again, to preserve backwards compatibility, `.sqd` is still a valid extension for the marker file(s).
+
+If there are multiple files with marker coils, the marker files must have the
 `acq-<label>` parameter and no more that two marker files may be associated with
 one raw data file.
 While the acquisition parameter can take any value, it is RECOMMENDED that if