I don’t believe there is such. How for instance, can the app know in which order the colours should sort or that you want a grid 2 columns wide as opposed to 3 or &, etc.? I don’t note that to argue against the need, but surface the hidden assumptions.
So, what is there at present?
- Cleanup view tab. That can give you a grid layout but doesn’t itself deal with order/segmentation.
- Force Directed Layout: 'Dance'. Interesting but not pertinent here.
Map layouts will use the $OutlineOrder, when per container (i.e. map) map may be modified by $Sort and $SortAlso (see more on sort).
So if I take this set of notes (note the outline ordering):
And sort to grid:
I get the items in $OutlineOrder. I think the number of columns used is set internally by the app based on the number of items and/or available visible screen space in the map pane.
But, if I set the map’s $Sort to ‘Prototype’, i.e. each note’s $Prototype, and apply clean-up to grid again we get this:
Same grid size but the notes are now arranged (permanently moved in $OutlineOrder) sorted by prototype. The prototypes are sorted in A-Z order (blue/green/red) and within the grouping the pre-existing outline ordering is used. So b2/b3/b1 as per the previous grab above. If $SortAlso were set to ‘Name’ (i.e. using $Name), and we run grid again we get:
Of course you could set $SortAlso to some other attribute value, even a user attribute holding a specific order you wish to maintain. Indeed, I suspect you’ve used $Color as a proxy of prototypes as I have here for clarity. But you could be sorting on any (attribute) criteria, $Prototype or otherwise
Bear in mind:
- grid clean-up works on changing $Xpos/$Ypos, i.e. the {x,y} position on the map and doesn’t affect $OutlineOrder.
- $Sort and $SortAlso change a note’s $OutlineOrder. That doesn’t show in the map but it does affect outline view (in case that matters). Also, removing a sort (i.e. setting $Sort to no value) has no change beyond the sort not being re-applied. IOW, you can’t reverse back to a previous sort (unless you capture the ordering in a user attribute and re-sort on that).
- The sort (i.e. $Sort and $SortAlso settings) must be applied to the Map’s container and not to the notes on the map. This is why in my demo (file below) I’m not using the root-level map. There you’d have to set the doc default for $Sort which would sort not only the root map, but all maps in the doc as they inherit the default. In truth, unless just messing around or sketching, I’d advise always doing serious map work in a container†.
So far, so good… But to me the next reply might be either/both:
- “Fine but I don’t want to alter the outline order”. Then you’re limited to what the grid cleanup alone can do.
- “Fine, but I want a different ordering of prototypes”. OK, it’s a bit more work but here’s a solution. Add a Number-type prototype $MapSort and for each prototype set a number. Then use that as the sort, instead of $Prototype.
Here’s what the latter look like if I set my red prototype to $MapSort 1, blue to 2 and green to 3. Previously the sort on $Prototype gave us order blue/green/red. But sorting on $MapSort and $Name then cleaning to grid:
Whilst I don’t think your starting goal is necessarily achievable in the fashion stated, I do think you can get close to it.
If i’ve misunderstood the question, apologies and please clarify what I’ve missed. 
Oh, and here’s the doc I used for the test, in case it helps: MapSort-demo.tbx (175.3 KB)
†. You can select notes and drag them into a container in map view, or in Outline add a note above (in outline order) the notes to be demoted, select all the latter and hit tab. Note that adornments can only be drag-moved in map view as they can’t be seen in other views. Regardless, all existing {x,y} map positions are lost as the items are drawn in ew positions on the new map. It’s a know limitation - another reason to start map work in a container from outset!