The issue comes down to how things are "parsed" when the skin is first read after it is loaded or refreshed. Section variables in options in measures and meters are "resolved" when they are "read". Resolving those Inline Lua section variables causes the Lua to execute the function.
So any of the Inline options like those calls to Lua will actually be "executed" when they are read, which will happen when the meters are first evaluated. Then they will be executed a second time, during the first update of the skin.
So even though you have Update=-1
in [Rainmeter], those kinds of Inline operations will be executed twice.
I think you would need to have the Lua ignore the first call to the function. More or less set i = 0 and then test for i > 0 in the loop.
Important Final Note
Any inline Lua used in options in measures or meters are resolved when the skin is first read and created on load or refresh. This is the same for all [SectionVariables] in Rainmeter.
During this "initialization" phase of the skin, before the first actual "update" of the skin, the value of all measures will be set to an initial numeric value of 0, and if applicable, a string value of "". This will normally be transparent, as before any "result" of the inline Lua is "used", before the skin is "drawn" for the first time, all measures and meters will have been updated and the correct and expected results will happen. However some care should be taken to ensure that a one-time initial value of 0 being passed to your Lua doesn't cause any logic or formula errors.
In addition, the Initialize() function in a Lua script will only be executed during the first update cycle of the skin. This means that if you are defining and setting some default values for variables in Initialize() in your Lua, those values will not be visible before the first skin update, which will be after any inline Lua in measures or meters are first run. This may cause "nil" values to be seen and result in errors.
In many cases, this can be resolved by defining and setting these variables in the global scope of the Lua script, outside of any function block. This global scope will be executed during the initialization phase of the skin, and the values will be immediately available. The global scope of Lua has not been much needed before in Rainmeter, but with inline Lua it can be valuable.
Again, in both cases, this all will generally be transparent and of no consequence, since by the time the skin is first drawn, at the end of the first skin update, all will be well. This issue should be kept in mind however, if you find you are getting single initial error messages in the log.
Inline Lua used in bangs in actions in the skin will only be executed when the action is executed, and so will not display this behavior. They simply can't be executed before the first update of the skin.
So the behavior will happen when an Inline Lua section variable is used in an "option" on any measure or meter, but NOT when the Inline Lua section variable is used in a "bang" in an "action". Section variables in "actions" are not "resolved" when they are "read", since it is not needed to initially "create" the measure or meter in question. In that case they are only resolved when the action is triggered.
P.S. I think you will find that OnUpdateAction=[&Lua:Example()]
doesn't execute at all, since it is an invalid / error call to the function that is expecting a value to be passed to it to populate the variable "meter" in the Lua. You can't specify an "argument" in the definition of a Lua function, and then just not send one. Lua will just bark at you in the log.