Initially 4.1 worked the other way round but it was switched to maintain compatibility. It should now behave the same as 4.0. I believes it's been this way for all the RCs.

I don't think there's a bug here. The docs for flex appear to be correct about the use of an undefined value. However, in your example the flex is not undefined because it is overridden by the defaults. I don't believe anything has changed from 4.0 in that regard.

I tried overriding the flex property with 0, null, and undefined in RC2 and each option resulted in the flex property overriding the config passed in by defaults. I did the same in RC3 and see that 0 and null override the defaults config, but undefined does not.

As soon as I loaded up RC3 when it was released I my flex layouts with flex undefined were all failing so I checked out the docs to see if undefined was no longer valid as a way to dismiss it in the flex layout, but RC3 docs still say 0 and undefined are the way to go. I changed each failing instance with flex: null and it works to dismiss the container from the flex layout, but wondered if it was a bug since the docs still say undefined or 0.

I've just tried this myself. It seems the priority switch occurred between RC1 and RC2, not before the RCs as I claimed previously.

Using either RC2 or RC3 I get the same behaviour as 4.0.7.

Perhaps we're reading different sections in the docs but I don't see a mistake. I'm looking at the docs for the config option flex, which appear to be correct to me. Using undefined as a flex value will cause it not to be flexed, however in your example the flex value is not undefined due to the use of defaults. I don't believe the way defaults are applied has changed at any point.

Ok. I was thinking that any configs on the items would override whatever was in the defaults config.
"Defaults are applied to both config objects and instantiated components conditionallyso as not to override existing properties in the item (see Ext.applyIf)."

If I use flex: null it does override the flex, but not if I used flex: undefined. Was just thinking that undefined would override it based on what I was reading here:
"This configuration option is to be applied to child items of the container managed by this layout. Each childitem with a flex property will be flexed (horizontally in hbox, vertically in vbox) according to each item'srelative flex value compared to the sum of all items with a flex value specified. Any child items that haveeither a flex = 0 or flex = undefined will not be 'flexed' (the initial size will not be changed)."

Though, I'm starting to suspect I'm must misreading the docs and shouldn't have been using flex: undefined in my app up to this point. Just brought it up because as I updated from RC2 to 3 it was something I had to go and update to fix my layout.

For what it's worth I just re-tested to make sure I'm giving a more accurate report. Below is the test script and the results in IE8 from 4.0.7, 4.1 RC2, and 4.1 RC3. Looks like a change between 4.0.7 and RC2/3. Maybe 4.0.7 was the buggy version and 4.1 fixed it? The documentation still throws me a little if this is the intended behavior, but I can certainly live with it.