It can save time but it’s limited use. The chance you can reuse the session is less than you may expected. Many people quits REPL and reenters into it because they want to redefine a struct or they install new packages, which means that the old global state is wrong and you should not reuse it. Now caching everything takes time. If you can’t reuse this cache enough times then the benefits you get from cache cannot compensate the time you spend on making cache. So no, caching everything is not the right way to go.
Of course for those people who are not package developers they can benefit from this type of caching, because they seldomly change their package environment not redefine struct. But this is too restricted, besides the technical difficulty of implementation.
It’s unknown to the user whether the session is in the middle of a method call. Because Julia is multi-threaded and there might be Tasks running at the backgrounds, let alone locks, opening sockets, libuv handlers or pending signals. What’s more, “saving the session to be possible in a middle of a method call” is exactly what may happens if you want to expose this feature to the user. Because users may call this function (let’s name it checkpoint()) in REPL session when he thinks his work is done and he’s ready to place a checkpoint to save his work, and the running REPL itself is in a middle of method call (the function run_repl). Now you see how complicated Julia is. Julia’s runtime, Base library and compiler maintain many states that are hard to serialized, and it’s meaningless to serialize them.
Given this, cache cannot be easily done for these runtime. So user must be careful to not use these kinds of constructions in order to be able to produce a cache (or you can serialize them and raise fatal error when user tries to use it), which imposes another restriction on this method. In summary, caching global state is time consuming, difficult and non-beneficial.