Adding one line to mlc_remove as such:

local function mlc_remove(uid, keep_entities, to_be_mined)
guis.close(uid)
if not keep_entities then
local mlc = out_wire_clear_mlc(global.combinators[uid] or {})
if not to_be_mined and mlc.e and mlc.e.valid then mlc.e.destroy() end
end
if CombinatorEnv[uid].on_remove then CombinatorEnv[uid].on_remove(uid) end
Combinators[uid], CombinatorEnv[uid], global.combinators[uid], global.guis[uid] = nil
end

allows me to write a
function on_remove(uid)
--clean up stored data when the mlc is killed, deconstructed, or mined
end

Adding one line to mlc_remove as such:

local function mlc_remove(uid, keep_entities, to_be_mined)
guis.close(uid)
if not keep_entities then
local mlc = out_wire_clear_mlc(global.combinators[uid] or {})
if not to_be_mined and mlc.e and mlc.e.valid then mlc.e.destroy() end
end
if CombinatorEnv[uid].on_remove then CombinatorEnv[uid].on_remove(uid) end
Combinators[uid], CombinatorEnv[uid], global.combinators[uid], global.guis[uid] = nil
end

allows me to write a
function on_remove(uid)
--clean up stored data when the mlc is killed, deconstructed, or mined
end

For context, this is useful for combinators that modify _api.global, so that they can remove their contribution to global state.

For instance, I update:
_api.global.crafting[productName] = _api.global.Crafting[productName] + product.count
whenever I start crafting a new item, and subtract it before I switch recipes. But if the MLC gets deconstructed in the meantime, I don't have a way to remove the currently crafting products from the table, so that production stays on the crafting table forever.

Created pull request for convenience:
https://github.com/mk-fg/games/pull/7

At first I thought to merge it, but then needed to update changelog and mod version and couldn't think of how to even describe the change, which I think is a good indication of why it shouldn't be there :)

First of all - shouldn't work, factorio should strip that assigned function on save/load, and issue a warning about it, if not just break the save.
Afaik saving compiled lua code in globals is not supported, which is why this mod works around it by recompiling all mlc code into locals.

Second, if this should be documented as "you can go into this mod's globals and assign on_remove there", that's really bad.
Much worse than _api, it'll 100% crash the game on any errors in there, and what you're doing is changing this mod's behavior, not just checking stack sizes via api.
If one is to go that route, I think doing that properly in control.lua is the way to do it - can just add custom on_build, on_remove and any number of other functions there for your customized game.
You'll know what you're doing at that point, will have proper tracebacks on errors, all functions stored in proper .lua files, etc, and not have random code junk dumped in savefiles.

And if it's not to be documented and supported as public API (and as mentiond, it really shouldn't be), then there seem to be not much point adding it here - no one will know about it anyway, and you can probably just use local mod fork with any number of such modifications much easier, rather than relying on all these untested/unused internals to work after random upstream updates.

I think in general when you need stuff like this, it's a good indication that you should just forget about this MLC thing and make your own proper mod instead - it'll be same exact lua code using factorio API, but much easier to reuse, properly structured in files, proper errors, and generally much easier to work with.
If you want to interact with it from MLC snippets, there's LuaRemote API which should allow you to call into any complex mod logic from MLCs, no problem.

Ah, I assumed it would just strip it out on save and recreate it when the combinator ran the first time after load. At least that's what it seemed to do with a quick test of creating an mlc with an on_remove function, saving and loading, and then removing the mlc.

I can understand where you are coming from... with the stated purpose of the mod, I don't guess you could even send out a single tick pulse before the internal combinators got deleted, so you couldn't really use it for anything unless you are storing mod-global data on _api.global.

MLC gives me something building my own mod never can - the ability to test changes without restarting the whole game. That's a huge productivity increase for the limited time I get to play. But I totally understand if you don't want to support it since it is going outside your intended scope. I'll just maintain that change in my own copy of your mod.

Given the CC-By-SA license, it sounds like you wouldn't have a problem with me making a fork with a greater focus on dynamic api access, with attribution and the same license, of course? I could imagine a mini in-game IDE with "file" support to let you organize and reuse your code across multiple controllers, all the _api stuff being directly in the environment, etc.

MLC gives me something building my own mod never can - the ability to test changes without restarting the whole game.

You don't need to, just save/load and factorio will load up all the new scripts as well.
It's only the prototypes and graphics that it loads with the game. Iirc there was a good article on the wiki about how/when it all works.
But yeah, you just edit control.lua, press load, enter-enter and play with new stuff.

Given the CC-By-SA license

I think that's the one that was on the predecessor mods, which this one is loosely based on.
Myself I just think all copyright/IP is nonsense, not how culture actually works, and should be abolished, so fork away! :)

I could imagine a mini in-game IDE with "file" support to let you organize and reuse your code across multiple controllers

Don't think you can use actual files in factorio, so that'd probably be a virtual filesystem for storing code in globals.

with the stated purpose of the mod
all the _api stuff being directly in the environment, etc.

It's kinda interesting that these exact two things are what I explicitly didn't want to have in the mod.

That's why I picked SandboxedLuaCombinator as a base over vanilla LuaCombinator2/3, despite it being a bit more broken and hacky.
But it played within the rules of the game and was intended for signals-in/signals-out operation, and not some kind of powerful modding API, just combinator stuff.
Iirc LuaCombinator3 goes way more into "modding tool" territory actually.

And LuaCombinator2/3 have syntax highlighting and IDE features, but I really disliked these, given how much input lag they tacked-on (making textbox nigh-unusable for me), for how terribly they worked, how much code and complexity they added.
So removed all those, but people actually brought up wanting more IDE-ish stuff couple times, which I can't imagine using myself, maybe I'm weird in that :)

Dunno if you actually need combinators there, as adding a general modding console might make the mod a 10-100x simplier, to make/edit abstract code that runs on whatever hooks or LuaRemote calls, and then MLCs with actual combinator code can be used to call into that, load/run code from there, query db, etc.

You don't need to, just save/load and factorio will load up all the new scripts as well.
It's only the prototypes and graphics that it loads with the game. Iirc there was a good article on the wiki about how/when it all works.
But yeah, you just edit control.lua, press load, enter-enter and play with new stuff.

TIL. Guess I just made assumptions based on other games I've modded. I'll have to try it out.

Myself I just think all copyright/IP is nonsense, not how culture actually works, and should be abolished, so fork away! :)

Totally with you on that. Open source licenses pretend to be "free" when their whole purpose is to take freedoms away.

Don't think you can use actual files in factorio, so that'd probably be a virtual filesystem for storing code in globals.

Yeah, that's what the quotes around "files" meant... not real files, strings in a table with names for keys.

It's kinda interesting that these exact two things are what I explicitly didn't want to have in the mod.

Totally respectable.

Iirc LuaCombinator3 goes way more into "modding tool" territory actually.

May have to see if updating the config is enough to get it working on 1.1 and see if it is worth starting from there instead.

And LuaCombinator2/3 have syntax highlighting and IDE features, but I really disliked these, given how much input lag they tacked-on (making textbox nigh-unusable for me), for how terribly they worked, how much code and complexity they added.
So removed all those, but people actually brought up wanting more IDE-ish stuff couple times, which I can't imagine using myself, maybe I'm weird in that :)

On second thought maybe not :) To me syntax highlighting isn't that important. Code completion might be cool, but at that point I'm just going to write in vscode and build some sort of client-server approach to getting the code in game... or just write a mod and save/load....

Dunno if you actually need combinators there, as adding a general modding console might make the mod a 10-100x simplier, to make/edit abstract code that runs on whatever hooks or LuaRemote calls, and then MLCs with actual combinator code can be used to call into that, load/run code from there, query db, etc.

Well right now I need an entity in the world that has circuit connections, because I enumerate the connected entities to know which ones to automate and which ones to leave alone. You can think of it as a networked, smart crafting combinator to allow it to scale out. Maybe that's the mod concept though, and I build this into a dedicated entity that does this one job. Then I could make crafting machines accept circuit connections as well, so I wouldn't have to infer which crafting machines are in view from the drop locations of connected inserters.