In a nutshell...  The contouring routine that Don uses first generates a surface map like you have been discussing.   Any contouring algorithm must do this.   So what Don is saying is that he likes to take the same surface map that you create, and take it a step further to group closely related cell values into polygons of a single value.

As to creating the surface, we only have two options at this point.  We can average the sites that fall within a cell, or we can generate a cell value based on an Inverse Distance Weighted algorithm, using the cell centroid as the anchor point for the search radius.  I'm sure you know how an IDW routine works.   But we do have a little twist that nobody else offers.   We have a Plateau radius in addition to a search radius.   This is a distance that we say is the minimum significant distance.  Any site within the plateau radius is treated as if it were at that radius.    As you are aware, in a pure IDW scenario, a site that is 50 feet away from the centroid will only be 1/10th as important as a site that is 5 feet away from the cell centroid.   Given a combine header width of 30 feet, and some amount of "smoosh" within the machine, it seems ridiculous to say that a site 5 feet away is any more important than 20 feet away.   And, in my opinion is not a lot more imporant than 50 feet away.   So, with a plateau radius of 25', the site at 5' gets calc'd as if at 25', and only becomes twice as important as the site at 50'.

Our default IDW parameters for grain are 100' search, 25' plateau, and inverse weighting to the first power.

Don may very well generate the underlying surface for his contour map at something like 20' or 25' resolution.   That surface will have very smooth gradiant changes from cell to cell.   And then, as he has indicated, he defines a set of contour breaks that he wants to see, and he generates polygons of similar cell values.

If he chose to, he could quit at the surface generation and have a raster based Rx (well, I guess I'm merging yield processing with Rx generation, but you know what I mean).  Rasters generated in this manner though, will almost always express a smooth transition.

Ok... as software author, we do everything we can to avoid imposing agronomy philosophies.   Hence the availability of surfacing or contouring, and the ability to use IDW or use cell content averaging.    But, I used to farm, so I get to give my two cents worth of personal opinion.    I would never use small cells and use content averaging.    There are just too many places where the noise in yield data will give you drastically different adjacent cell values, and I don't think that is a fair depiction.   And, yeah... can cause controller issues, too.   You alluded to this yourself.     But... I do think I would tend to stay with raster surfaces rather than contour polygons.    I like the smooth transitions form 90 lbs to 110 lbs across three cells, rather than an abrupt line causing a 20 lb difference.  

And, one last comment... (yeah, right).   I see people talk about creating rasters that are equal to their planting width or harvest width, etc.   At first glance, it seems like that would minimize the amount of time a machine is covering two adjacent cells.  But my experience with rasterization is that most rasters are generated square to the map, which is usually projected to a cartesian coordinate system that may not be square with lon/lat.  All controllers that I work with other than Flexi-Coil require the raster to be square with lon/lat... not UTM Zone 16 North, for instance.  So the Rx generation process may have to re-rasterize the cells anyway, and they might not end up square to the fences, so you would ALWAYS be covering two cells.    I like to generate Rx rasters that are 1/3 of the intended machine width, figuring that the Rx rate will always be figured from the center of the machine, and that raster will be a smooth value between the rasters on either end of the machine.

If Tim is in a good mood tonight, he might post some illustrations :)

So much for a short response :(