The idea is as simple as the answer is complicated, multi-facetted and varied depending on who you ask. In this post I'm going to give a basic explanation of WPS tracking, explain why you might want to add _nomap to your SSID, why maybe you wouldn't and give some general advice on how to adapt to this situation regardless. Besides giving people new to the topic a starting point, I'd like to provoke thought and discussion on whether GrapheneOS should implement this in some form.
Introduction
For those that don't know about this, here's a short explanation: Companies like Apple or Google and projects like beaconDB or WiGLE collect hardware identifiers like MAC and BSSID of wireless radios in the proximity or their users devices. Their databases can be used for things like WiFi-based Positioning System (WPS).
Imo this means there are valid uses for this, and I even personally contributed to beaconDB in the past, but obviously there are privacy concerns. If you don't include personal or otherwise problematic details in your SSID this isn't worth losing sleep over for most people, especially concerning their home networks. As long as the AP uses a generic SSID and doesn't move, you have the anonymity pseudonymity of the masses. And that's exactly the problem with your phone's hotspot: it moves.
At least for generic SSIDs, a threat actor can't just use these databases to identify which network belongs to whom. However, if you repeatedly use your phone's hotspot while away - maybe on your way to and from work, maybe while visiting your family, maybe while traveling to a protest - there's an increasing amount of data that, while individually not that useful, can be used to create a profile of the person tied to the AP. At some point, its movements will only fit you and reveal things like your home, your hobbies and habits, your social circle, your workplace, your religion, your political activism, etc. And that doesn't have to be the end of it, as your info can function as a datapoint in your friends profile and so on.
What to do as user?
Now, the most important thing is to simply keep this in mind. As is true for all radios, try to use them as little as possible and only when you actually need to. GrapheneOS features are already a massive help on that front. And if you really don't want anyone to know you were at a location, turn on airplane mode and turn off location, WiFi, Bluetooth, Hotspot and NFC permission. Also don't use firstnamelastname as SSID.
There's nothing that can replace the advice above, but finally getting to the point of this post, something that you could do in addition to it: If you include _nomap at the end of your SSID, many entities maintaining such databases, including Apple, Google, beaconDB and WiGLE, will treat this as an opt out and thus exclude the AP from their database.
Why isn't _nomap a _nobrainer?
So, problem solved? Well, no. Shockingly, opting out of mass surveillance and data collection like this doesn't actually fully solve the issue and simultaneously comes with strings attached.
On one hand, not all database providers respect _nomap and even if they do, you'll just have them to actually respect the opt out. It also needs to be implemented in a way that fully prevents such APs to be stored on any server, even for a very short amount of time. Ideally the devices collecting the data would filter out these APs before sending the data to the server. How this is done in practice, I don't know, and no one can say for sure whether Google and Apple fully honor this and even implement it in a way that prevents even law enforcement from obtaining some info. Maybe they do, but trust as only layer of defense between your data and corporate interests or other threat actors should always be treated as the very thin shield that it is.
On the other hand, adding _nomap at the end of your SSID somewhat contradicts the earlier advice of using generic SSIDs. It doesn't tell everyone who you are, but it does tell everyone that you're more willing and able to protect your privacy and identity than most - a person of interest, one might say. You could compare it to using a not very trustworthy VPN that also has few users. The most analogous feature I can think of is the "Do Not Track" string in browsers, which should generally be left in the default state because it serves as additional fingerprinting vector while providing dubious but certainly limited advantages. I'm of the opinion that _nomap provides more benefits and doesn't immediately hurt its purpose as much as DNT, but the attention it might draw could very well mean it working against you long-term.
There's another!
Before we get to the conclusion, I want to mention _optout, which works in almost exactly the same way as _nomap. The only difference is that _optout can be placed anywhere in the SSID, not just at the end, and is respected by Microsoft. To benefit from both, GrapheneOS could add _optout_nomap to the SSID. However, I'm not sure whether this is even still being used, so I didn't include it in the title.
Finally, there's the option of not changing the SSID in any way, but including an one sentence long recommendation/explanation on this in the settings and maybe link to a section on the official website that goes more in-depth. This might even be worthwile if the GOS team is of the opinion that you should not add _nomap etc to your SSID, just as a warning instead.
Conclusion
So, what to do in conclusion? There are really two seperate questions here: One regarding individuals and one regarding GrapheneOS as a project.
What you should do personally, depends on your threat model, which I haven't taken into account at any point in this post. There's definitely no easy or blanket answer, so I'll refrain from making up something here. I'll just say that, while certainly not achievable at large scale through individual actions, the more SSIDs have this added, the less each one stands out. The people that need protection against such tracking the least are the ones for which adoption would be least problematic.
GrapheneOS as a project has to take different things into account. For example, if almost all new GrapheneOS devices would use this, it might provide an easy way to identify GrapheneOS devices with good confidence from a distance. A lot depends on how widespread usage of this actually is, which I don't know. (Incomplete) mitigations here might include changing the default SSID further, for example to wifi_nomap, but might again make the problem worse instead of better. Coordinating with other OS devs would theoretically address this problem in a more meaningful way, but in practice Google just isn't going to make their own devices opt out of their data collection by default. Between research and outreach the drain of resources would quickly become completely out of proportion for any possible benefits from this.
Being limited by the info I lack, I'm unable to form a confident and complete opinion. Still, I would very much like to know where @GrapheneOS stands on this and suggest that, if the project's prosition is firmly on either side of the spectrum, a short section should be added on the website.
Of course, I'd also highly appreciate anyone else sharing infos or their own take on the subject. Anyways, if you read until here, thanks for your attention and have a great day:)
Links
Article about Apple's database: link
More info about router SSIDs and when to use _nomap: link
Google on opting out: link
OpenWrt Forum thread on the topic: link