One could possibly argue that we should use the real ATON symbol for these targets as well. See picture.
But my thought is that we should distinguish between official ATON with correct MMSI and these made up ATON?

Btw: Another sorted source file from my MMSINAME attached.
It is clear how innovative fishermen and others can be when programming an ATON with a mmsi number. Lack of standards is of course a contributing factor.
MMSINAME.txt

Hakan they should certainly have a different symbol or indicator maybe as a bogus Aton?, An Aton symbol with some overlay? like a "?" or "Fake" or something to identify.
Maybe a orange Line through the symbol, just like the transmitter picture above?

I chose the filled ring, like ARPA, because sometimes other things can appear than buoys with these fake mmsi. I've seen a canoe, which is more like a boat and then the ARPA symbol fits quite well?

Two questions:

1. Using your strategy, what is the practical risk of incorrectly identifying a valid vessel target as a fishing buoy?
2. Do the fishing buoys in your implementation provoke CPA error messages in OCPN?

1. If a "valid" vessel is one using a MMSI number according to standards it's no risk since the mmsi numbers used for these "ATON" are never assigned by any authority. The opposite that someone on their own initiative assigns a real ship a fake MMSI number can happen. Therefore, the ARPA symbol fits better than ATON.
2. Yes it would. Again like a ARPA target. But a god point. I'll check it.

The idea is good and useful!
But it will not be possible to identify most of the network buoys!
China, which sells most of these buoys, provides software for programming any MMSI. I looked at fishermen in the area of ​​​​Hong Kong and Taiwan. There are buoys, they are called without mentioning Buoy, the mmsi number is filled chaotically

Up here I'll say most of the buoys but of course not all. That's impossible without a (followed) standard.
In North Atlantic, see my picture above with some examples. There are some hundred identified with the present code.
For my so far test I use the series of mmsi as of below code captured from my MMSINAME.csv.

From your experience would we add more?

bool b_IsBuoyMmsi(int msi) {
  // IMO standard is not yet(?) implemented for (net)buoys
  // This "hack", based on real-world outcomes, is used instead
  msi /= 1000000;
  if (msi == 108 || msi == 109 || msi / 10 == 94 || msi / 10 == 95 ||
      msi / 10 == 87 || msi / 10 == 88) {
    return true;
  }
  return false;

I have a new unprogrammed Chinese network buoy, tomorrow I’ll see what’s there by default

If it's about to be programmed I'd suggest 94yyyxxxx . yyy equals MID>>country code. See here

And what's the "Pool of the nearest free numbers"?

An alternative could be the reverse.

Consider any MMSI number that does not contain a valid MID to be a "net buoy".

As you probably know, valid MMSI numbers include:
MIDXXXXXX (for ship station),
0MIDXXXXX (for group number),
00MIDnXXX (for coast station),
99MIDXXXX (for AToN),
111MIDXXX, (for SAR),
98MIDXXXX (for vessels associated with a parent craft),
8MIDXXXXX (for handheld VHF),
970XXYYYY, 972XXYYYY, 974XXYYYY for SART, MOB, EPIRB respectively,

You've provided the list of valid assigned MID's in your ink above.

There is also a MMSI prefix 979YYYYYY which is used for autonomous devices, although I understand these operate on a different frequency to AIS Channels 1 or 2 and at a lower power.

Good comment! We may explore it further:
For sentence !xxVDM message 18 and 19 (Class B transponder).
Consider
If MID >200 && <800 || >=970 as normal Class B (ATON)
Else AIS_BUOY (or should we designate that class something else. )
(Note: All in the range 0 - 100 or 111, e.g. Base or SAR, are not handled by message 18 or 19.)

Perhaps this is more programmatically effective than trying to make an implicit list for AIS_BUOY.
We will then find most of the MMSI that an inventive user can come up with without interfering with the targets that meet the standard?
Still, the main goal of this change is to avoid buoys and faulty MMSI appearing as a Class B target.

My intention is to PR this now. I have been using this supplement for a couple of months without any problems. I have tested here on the Swedish coast and also a url for the whole of Norway where several hundred net buoys are available to study. (I've also seen one with the name "Canoe". :) ) It can be of value, it is tested by the alpha testers who have the desire.

The code now connects with the remark to rather include the MMSI that do not meet the standards than to try to specify every possible combination that was my original test.

These are MMSI fulfilling standard and thus not a "net buoy"
if ((mid > 200 && mid < 800) || mid >= 970) {
The rest will be stated as a new class = AIS_BUOY.
Remember we are only handle targets received as class B by SignalK, N2k PGN 129039 and NMEA0183 AIVDM message 18 and 19 thus not interfering with Class A, Base or SAR stations.

Thoughts?

Now merged to master.