You kind of open Pandora's box if you do that, but that is bound to happen one day or another, so let's start:

0. What is the use case for having this? I don't mean this in a way that this should not be done, just that finding usecases will help us answer the questions below.
1. I think having arrays, axes and groups without scalars is bound to create frustration for our users.
2. I don't really like the name (but maybe I only need more time to get used to it). If the criterion to take or not take a variable is "data" vs "non-data", we could name them:
   local_data(), global_data() and data()/available_data()/all_data()?
3. assuming we do scalars, what do we do with simple Python structures: tuple, list, dict and set of data? and nested structures of those?
4. how do we handle functions and other more exotic/unsupported types? Just ignore them or warn if present (for functions that would be in most cases, so that would be useless I think, but no warning could lead to dataloss) or try to save them via pickle (or some other lib which can serialize anything)? I think that ideally we should have "known unsupported types" which do not warn, but than warn for other types. The result would be that if a user tries to use data in an unsupported type, he gets a warning that his data has not been saved.

You know how LArray is used in some in-house models. If we modify Session.save and Session.load so as to include non-LArray objects, users will wonder why it is not same when creating session from global objects even if they don't need them.

Well, the best is maybe to not fix this issue as long as a user doesn't ask.

@gdementen I think this issue is no longer a question. We now have Session objects that contain axes, groups and arrays. Still having local/global_arrays functions is quite inconsistent, don't you think?

Indeed, but there are open questions anyway: how to name the new functions and the other questions I raise above. Concerning the name, I still don't really like locals_to_session and globals_to_session.