Hi re problem:
just that in nightly build if one calls get_userdata one gets a userobject, with amongst other bits $user->data.
$user->data is what used to be returned directly in 3.2.1 if one called get_userdata.

So I have added a little wrapping function so that my code will work in both 3.2.1 and in nightly build.

That is incorrect. In 3.2 and before, get_userdata() returned all the user fields mixed with user metadata

Just to clarify that, Yes, The return value has changed, a WP_User object is returned instead of a dumb object. However, through the usage of magic methods, data fields (such as the meta key rich_editing), get_userdata(1)->rich_editing will map to get_userdata(1)->data->rich_editing, even though in a var_dump() or similar will not show these extra fields.. So you shouldn't need to use the code in comment:4 as it should just work (Side note: The code in comment:4 will actually break, in the sense that it will not include the meta fields, it'll only contain the user row data)

and then when I var_dumped and saw what I saw, I thought that was the reason. However on digging deeper I realised the call was in a loop however I was only getting the notice once . IE there was a data problem which resulted in the code having a userid for a user that was not there!

So anyway I learnt something - one cannot always trust a var_dump! (and to add more checks in the code!)

FWIW foreach ((array) $user as $key => $value) is a bad practice ASSUMING you only want the meta data. Assuming is bad practice too, especially when making assumptions about the way developers are using one of the most widely adopted platforms in this sphere.

I personally was doing exactly this to aggregate user data agnostically, so that we can render disparate elements for a collection of users with the minimum queries required. Fortunately this only took a wrapper function and a few lines of code to detect version and format an array accordingly if needed.

Going forward, I think it is crucial for WP development to maintain backwards compatibility.

While I agree that lazy loading meta is generally a great practice, it makes far more sense to introduce a new function that provides this lighter response, rather than overwriting existing ones potentially breaking code built to work on top of those existing functions.

Let's please consider the developers using the platform before pulling the rug out from under with a hasty modification like this, no matter how justifiable the intentions are.