Let me add my 2 cents in an effort to move this conversation forward. My understanding is that the current inheritance order is ('<' indicates 'inherits from'):

board:4gb-rootfs < board:common < parent:4gb-rootfs < parent:common

Is that correct?

The inheritance order I'd expect would be this:

board:4gb-rootfs < parent:4gb-rootfs < board:common < parent:common

That way, the board layout could adjust common options as needed, but anything specifically overridden by specific configurations would still remain effective (unless in turn overriden by the board layout).

That makes good sense to me, but before making a change like that I'd want some kind of automated test to ensure this doesn't break any existing images for any of our special cases.

That said, I'm not sure how to identify the existing special cases.

Yes, the current inheritance order is:

board:4gb-rootfs < board:common < parent:4gb-rootfs < parent:common

This is by design -- see:

https://chromium-review.googlesource.com/c/183391/

+sosa@ to see if this can changed to what mnissler@ recommends without breaking anything.

Ha, sosa's change is indeed an interesting input to this discussion. If I read the corresponding  issue 697967  correctly, the original inheritance order was this though:

board:4gb-rootfs < parent:4gb-rootfs < parent:common

I.e. the board:common not taking effect at all. If I'm not missing something, my proposed change to the inheritance order would still be sufficient to address the underlying problem that sosa's change addressed.

Then again, no matter what inheritance order we choose, there'll always be a situation for which it doesn't work out. Given that, there's no right decision and we'll likely be forced to add a duplicated parameter somewhere to work around unintended inheritance results at some point in time.

My gut feeling is still that my proposed inheritance order is more natural than the currently implemented one, but I think it'd be totally fair to conclude that there's no ultimate answer here and live with the override situation we currently have in the tree.

Regarding verifying against the existing disk layout configuration: That should be a simple matter of running a script that evaluates all disk layouts against all boards before and after the change and report differences in results. Or am I missing something?

I think we'll break something if we change something (beaglebone usb see  crbug.com/335269 ).  The current layout strategy is well documented (~/trunk/src/scripts/build_library/README.disk_layout) and we at least understand it now, so marking this as won't fix.