Rec group set to shank_id in NP 2.0 multishank, but to probe_id for NP 1.0

Hello!

SpikeInterface version 0.104.3

As I understand the recording group gets automatically assigned "probe" as group for NP 1.0 and "shanks" for NP 2.0 multi-shank.
This is not necessarily an issue, but created some confusion when sorting began and the single NP 2.0 4 shank probe got split into 4 separate probes folders.
My question is: is there a particular reason for this choice? Can I safely change grouping for NP 2.0 multi-shank probes to "by_probe" rather than "by_shank"? Will that lead to some issues downstream? Because I don't know if any other processing relies on these groups to be shanks and not probes.

Here is a recording with two NP 1.0 probes and property > group of this recording assigns IDs 0 or 1 for each probe:

And here is a recording with single NP 2.0 multi-shank probe and property > group of this recording assigns IDs 0, 1, 2, 3 for each shank:

Let me know if this info was specified somewhere and I missed it.

I'm also wondering what would happen if I were to have two NP 2.0 multi-shank probes in a single recording. What would group property assign and where would shank id information go?

No files or tests are named in the report. Start from the recording's group property and the NP 1.0 and NP 2.0 multishank behavior described here; determine how by_probe and by_shank behave with multiple probes, where shank IDs are retained, and document the rationale and downstream implications.