I am trying to build a system to track local consumption of items to try to predict future order quantities. In order to do this I created a stateful class that I save into var.items{}. This class includes functions and tables. However when I load the game from save, the var.items{} only has the index keys. All of the functions and tables of variables are gone.

What is the best way to save variables so they are remembered between game loads?

You should be able to save/load any values in that "var" table or just globals within that combinator environment, except for functions.
Last I checked, factorio did strip all functions (as in var.a = function() ... end) from saves and issued a warning to its logs about each one.

I think you can work around that by creating and storing function wherever you call it from (e.g. method-like key in a table), if you detect that these are missing, and afterwards or otherwise just run stuff normally.
E.g. if not var.myfunc then var.myfunc = function() ... end; var.myfunc()

But don't think there should be any issues with other lua data types in those tables and environment, at least to my knowledge.
It'd indeed have been rather weird if all these combinators reset whatever they were doing on every load.

Oh, and special shoutout to C++ stuff that you can get from factorio modding api - those won't even allow you to save the game, if handled anywhere but in locals :)

Also check out State Machine example thread next door - https://mods.factorio.com/mod/Moon_Logic/discussion/62299bb657d5edc3b2da26dd - it might be the kind of stateful thing you're looking for, but implemented a bit differently.

Yeah, I looked through all of that. The root of my issue is that I am tracking the rate of consumption for each item INSIDE the function that is stored in var.items. I do this so I can use self.whatever. Then when Factorio saves/loads it clears the function so that I lose the tracked info.

I guess the best work around would be to save the data tables separately from the function (Basically move away from a class mentality).

Also, thank you for the great mod and the fast and informative responses.

On a completely separate note, the prefix that you add the signals currently do not get removed when using the signal as a key in the _api. tables. I found this out when I was trying to lookup the stack size for SE items. A number of them get the '#se-filtered-miniloader' treatment, but the game itself only knows it as a 'se-filtered-miniloader'.

I wrote a quick work around on my side to strip out the prefix if it has one, so it is not a big issue, but might stump someone else.

tracking the rate of consumption for each item INSIDE the function that is stored in var.items
I guess the best work around would be to save the data tables separately from the function (Basically move away from a class mentality).

Don't think I understand what exactly is "class mentality" in lua, but presumably "inside the function" means its locals, and then I think another workaround might be passing the global state-table to some class-init-func and storing everything there instead of its locals.
Then presumably when function gets cleaned-up, you'll still have that pseudo-locals table to init the thing with after load.

prefix that you add the signals currently do not get removed when using the signal as a key in the _api. tables.

Yeah, but these internal signal IDs are not supposed to be used with factorio APIs anyway, as it doesn't have string IDs for signals, uses tables like {type='item', name='se-filtered-miniloader'} as SignalID objects.
And of course it's not really the purpose of these combinators to be a gateway to factorio modding API, despite plenty of people apparently using them that way :)

There can also be even weirder prefixes, like when red/green inputs are mismatched, you can get e.g. red/se-filtered-miniloader + green/se-filtered-miniloader, which you probably wouldn't want to be stripped, as whole point of them is to disambiguate two different values sharing same factorio SignalID "name".

which you probably wouldn't want to be stripped, as whole point of them is to disambiguate two different values sharing same factorio SignalID "name".

I think this should actually apply to #se-filtered-miniloader - iirc that prefix is only added if your game has SignalIDs with different type= and same name.
It's probably some mod that copies all type=item signals to type=virtual ones in your specific mod setup, so using that signal name without prefix is always ambiguous.

Iirc such mod was the reason for implementing those prefixes at some point in the first place, but don't think I remember which exact one it was.