The (traditional) command for saving modem configuration is AT&W, and from the syntax of it you can tell that it is an old command (because it is basic syntax as opposed to extended syntax, see V.250 for details).
In fact the command is so old that the origin of it is unclear, and support for it and exactly what it saves is 100% manufacturer specific. When I worked at Ericsson (and later producing the base platform for Sony Ericsson and other manufacturers), we did implement AT&W but I do not remember in detail what was saved. But generally, things saved would be serial connection related things like AT&C and AT&D, as well as data call settings like AT+CRLP, AT+DS etc.
I am relatively sure that preferred phonebook or sms storage was not saved by AT&W, because for all the settings listed above, those were settings used directly by the AT command handling module for its own behaviour or setup of calls. On the other hand, handling of messages and phonebook was done by other modules in the system, and it would have introduced additional complexity if the AT module had to communicate with those entities for preferred storage settings. So when not absolutely needed, it was not done.
And if you think What, complexity? How hard could that be?, well consider the following. Who should own those settings? The only (architecturally) sensible solution would be for this to be owned by the domain specific modules, e.g. not by the AT module, which then would mean that the AT module would have to query this from those entities on startup. But the AT module must be ready super early in the boot process (after all it might be used to unlock the phone with AT+CPIN), so it is in absolutely no way acceptable to delay startup of the AT module until such query answers had been received, which then means that it would have to start up in a partially configured state which definitely means added complexity.
And for those that remember phones from 10-20 years ago, those were underpowered devices1 that ran at full speed for a significant time doing what it needed to start up, resulting in a very sluggish UI the first minute or minutes. Accessing the SIM card was particularly slow, and the phonebook could easily use minutes to finish reading a large list from the SIM at startup. So both depending on those and putting additional workload onto them would have been bad.
TL;DR: Try and see if AT&W saves it. If it does, great, if not you have to set it manually every time. After writing all this I am very, very sure that we did not save any sim/phonebook preferred storage settings. And while other manufacturers of course can, I do not think you should be too optimistic.
1
The first phone I worked on had just 64kb of RAM on our CPU, 34kb of which was used for RLP+L2RCOP transmit/receive buffers. Using a realtime operating system that not necessarily used pre-emptive scheduling (most of the phones eventually did, but not the early ones). And every process was statically defined, there were no just let a backgound thread do the work.
