Testing was done on GPS - it's tedious and time consuming but the only way to be sure of what will happen when the map is actually used on a GPS.
I don't think it's the basemap since (1) the basemap appears outside my map's border and is not hatched (2) the hatched area is new, appearing only after the addition of the polygon. My belief is that there are "background" map problems generated by the polygon creation process.
Spending another two days on this, I did achieve partial success, producing two "almost correct" versions. One displays the pink polygon below the trail+contour+stream lines at the lowest levels, i.e. those at which the contour+stream lines appear - but if I zoom out to the level when only the trails should appear then the polygon disappears (note: for this version no hatched area ever appears). But since displaying the wildfire area at higher levels is important for planning purposes, I found this unacceptable.
The second result displays as above at lower zoom levels but also displays the pink polygon at the higher zoom levels, below the trails. It's drawback is that hatched area appears outside the map's domain, obscuring the basemap below, and is ugly. But it is the best I can do and is useable. I console myself with the fact that in 2 years I should be able to remove the wildfire polygon and get back to a non-ugly map.
Achieving the latter required a kludge, by adding 4 infinitesimally small polygons to the polygon .mp file, one polygon at each corner of the outer map region as set by all the non-polygon .mp files. (Prior to the kludge, with just the wildfire polygon, the hatched area appeared outside the rectangular region bounded the wildfire polygon, so trail lines were being displayed atop hatched area which was not acceptable - with the addition of the 4 polygons, the hatched area has been pushed further out, beyond the overall map area, and so is acceptable.)
Since it seemed like I was "close" to a non-ugly solution, i.e. having no hatching ever displayed (just as prior the polygon addition), I tried many, many different slight changes (feeling like the proverbial monkey typing for an infinite time to accidentally produce a Shakespeare masterpiece) - but to no avail.
To document this for any cognoscenti who might later be interested, historically I've been creating an Garmin IMG file by creating a trail .mp file and compiling it with mkgmap, then doing a subsequent mkgmap run which combines that img file with img files previously created for the contours and streams, to produce the final IMG. And it worked well - no hatched area ever appeared. For the wildfire, I created a separate .mp file which I compiled separately, then included that with the contour and stream img files for the final IMG. My guess is that the hatched area is some "background" map problem - either
(a) one is being generated, or
(b) one is required but is _not_ being generated.
So I've tried variants such as
(1) adding "--transparent" to the polygon compile (which caused the pink polygon to overlay and blot out the contour+stream lines),
(2) moving the polygon .mp commands into the trail or stream .mp files (the latter produced the first "almost correct" version described above)
(3) changing the "DrawPriority" of the polygon .img file to be lower than that of the other .img files (which I was surprised to find did not change the displayed map),
(4) combining _all_ the .mp commands into a single .mp file (but the compiler rejected it as being too large),
(5) using cgpsmapper instead of mkgmap to produce the polygon .img file, with several variants ala the above, e.g. different transparencies (but results were the same),
(6) altering the specified .mp file "Level"s, etc.
Bottom line is that I've exhausted my knowledge and am ready to call this a dead end.
One final thing which might be informative. Starting with the cursor in the middle of the map, with no hash area appearing, moving the mouse horizontally causes the hashed area to appear with the boundary being at the lat/lon of the map perimeter (which is the same as the rectangle defined by the 4 corner polygons). Continuing to move the mouse outward, the hatched area grows and eventually fills the display until suddenly the basemap appears in the entire display. So there is a sudden jump between the hash area filling the display and the basemap filling the display. This seems to occur when the _entire_ display region is outside my map's domain - if just a small part of the display area extends into my map's region, then the entire display is hashed. (Very different from prior to adding the polygon, when there was no obvious boundary or transition between my map and the background map.)
Jack
Below is a screen shot for just a single pink wildfire polygon, showing hatching outside the rectangle around that polygon - adding 4 polygons at the map domain corners pushed the hatching outward