Some remarks by various people:

• Drivver: Commanders currently have a 3x3 footprint with a 2x2 movedeff
• lov: buggeroff checks use unit->radius

Is there a simple replay I can look at that shows this issue early on?

This replay shows it on the second batch of queued wind farms: https://discord.com/channels/549281623154229250/1286802236650815551/1287373051683541013

So this replay then? https://bar-rts.com/replays/13fdef6628d75c15d79c42c1c5930e5d

Engine 2555 affected
Engine 2511 affected!

BAR dac88466c4cf4b1cdc3a6738aafad3c5d06092c9 UNAFFECTED
BAR 1f5cf3cca3eee01d58715a92d7372241302e1c11 FIRST AFFECTED :
beyond-all-reason/Beyond-All-Reason@1f5cf3c

So this replay then? https://bar-rts.com/replays/13fdef6628d75c15d79c42c1c5930e5d

Yes indeed, but it turns out that a gameside change triggered the issue, namely a difference in collision volume or movedef footprint.
Latest BAR and any engine allows you to repro it in 2 seconds, but moving commander and then queueing a building to the left of it with just a single column overlap of footprints.

Note that I pushed a hotfix to the game: beyond-all-reason/Beyond-All-Reason@c090171
Which changes comm movedef footprint to 3

note from me
i dont see a need for bar to have a missmatch between footprint size and movedeff sizing in general.
im fairly sure that there are a number of units in bar that have this issue that have not been reported.
especially with the fact that i did adjust a number of movedeffs on units about two years ago.

i will be going through all of bars units and make changes to units that i find that have a mismatch on footprint vs movedeff sizing at some point and time

Engine should probably still handle this somehow. Either make units move according to the appropriate footprint or adjust mismatched footprint

Are there any good reasons for the unit foot print to be different from the move type foot print?

Otherwise we can force align the unit footprint to the movedef's footprint.

There are some possible reasons to have them different. Most of them seem weak so I think it's fine to change though.

1. adjust the size of the shape drawn on the ground which marks units that are selected. The built-in engine square does this, and AFAICT most existing selection widgets do so as well.
   

2. mobile units can be built by constructors, same as buildings. You can make a unit bigger to force some free space around it. Your fix fix bugger off issues #1694 seems to only adjust the size of individual units after they receive a movedef, and doesn't change the size of the whole type, so this should keep working as-is.
   

3. default engine Shift+Ctrl modifier for construction is to surround hovered unit, this uses footprint. This is just UI so games can reimplement it if they want, and it isn't that useful for mobiles.
   

4. maybe others? I'm going off the top of my head but anything I don't remember probably isn't too important. Maybe @GoogleFrog would want to say something.

It would be nice to modify mobile-mobile repulsion radius and profile (ie the force-distance function). But I would only use it and expect it to make sense when used to differentiate units within a pathfinder size. I made a PR ages ago with a multiplier for unit pushing size.

• Sprunk
  i agree with them being weak at best

1. adjust the size of the shape drawn on the ground which marks units that are selected. The built-in engine square does this, and AFAICT most existing selection widgets do so as well.

in this case i think it doesnt make sense for the footprint to be smaller than the movedeff. the selection square should reflect the area that the unit occupies. this gives the player to have the GUI reflect what is going on at the technical level without needing debuger tools or having to place a building to see the occupancy.

3. default engine Shift+Ctrl modifier for construction is to surround hovered unit, this uses footprint. This is just UI so games can reimplement it if they want, and it isn't that useful for mobiles.

footprints in bar go to as far as needed to cover the buildings. units shouldnt be exempt from this.

• lostsquirrel1

Are there any good reasons for the unit foot print to be different from the move type foot print?

IMO no. but i have not really seen use cases where this would be benificial.