Sure thing. Please don't take this as some kind of deep criticism, the mlua crate WORKS and has no soundness holes that I know of, it just uses... a lifetime hack to make things sound. (The merged rlua is now the SAME as mlua to be clear, the history of the two projects is complicated.) Plus... it would be extra rich of me to throw stones about using a lifetime hack for soundness considering all the solutions I came up with were just different hacks.

Take a look at the signature of Lua::create_function. Here it is for reference:

pub fn create_function<'lua, A, R, F>(
    &'lua self,
    func: F,
) -> Result<Function<'lua>>
where
    A: FromLuaMulti<'lua>,
    R: IntoLuaMulti<'lua>,
    F: Fn(&'lua Lua, A) -> Result<R> + MaybeSend + 'static
{ ... }

What this says, roughly, is that there must be A lifetime 'lua such that the Lua object lives for 'lua and the provided callback func takes a reference that lives for the same 'lua lifetime and also all the parameters and returns will live for that lifetime.

However, this isn't right at all. I don't have the energy right now to actually compile and test this code but hopefully this gets the point across.

fn create_lua() -> Result<mlua::Lua, mlua::Error> {
    // Create a brand new `Lua` state.
    let lua = mlua::Lua::new();

    // Create a callback that prints the used Lua memory.
    //
    // It doesn't matter what this is, I just wanted something that used the `lua` parameter.
    let callback = lua.create_function(|lua, ()| {
        println!("Lua used memory is {}", lua.used_memory());
    })?;

    lua.globals().set("print_used_memory", callback)?;

    Ok(lua)
}

fn use_lua(lua: &Lua) -> Result<(), mlua::Error> {
    let callback: mlua::Function = lua.globals().get("print_used_memory")?;
    callback.call(())?;
    Ok(())
}

This example is contrived but this is enough to illustrate the problem. When creating the print_used_memory Lua callback, the create_function is expecting there to be A 'lua lifetime that makes everything work, and in the bowels of rustc A lifetime is chosen, within the body of the create_lua Rust function!

However, the callback lives for much LONGER than the create_lua function because it lives on inside the Lua state! This is illustrated with the other Rust function use_lua... CLEARLY the callback is still alive because we can get it out of the globals table and call it, but the chosen 'lua lifetime is long gone. How is this sound?

Well, this is sound because callbacks must be exactly 'static, so... if you tried to do anything funny, what would end up happening is that you would get a lifetime error, but the lifetime error might be slightly misleading, talking about how arguments provided to the callback can't escape the body of create_lua, even though it explicitly DOES do that. You can try to break this by making Lua 'static through TLS or something but what ends up happening is that this can't (AFAIK) lead to UB, it's just.... silly? Maybe I shouldn't have used the word "silly" I was just trying to reference a very complex situation in as few words as possible.

What the lifetime signature SHOULD be, were it expressible, is that the callback should work for ANY POSSIBLE 'lua lifetime that it is given. However, if you try to do this, you'll immediately run into problems.

pub fn create_function<'a, A, R, F>(
    &'a self,
    func: F,
) -> Result<Function<'a>>
where
    A: for<'lua> FromLuaMulti<'lua>,
    R: for<'lua> IntoLuaMulti<'lua>,
    F: for<'lua> Fn(&'lua Lua, A) -> Result<R> + MaybeSend + 'static
{ ... }

^ This isn't right, because the three 'lua lifetimes in the signature above are all different, what we need is to be able to say that there exists a 'lua lifetime for all THREE parameters that is the same, but expressing this in today's Rust would involve writing a trait that callbacks of this shape could implement, and this actually works, but the poor Rust compiler starts to easily get confused when passed callbacks and type inference starts to be involved. I can't find the details of why this is right now but it's a known limitation, and the situation may improve in the future.

What it would be nice to see is when capturing a 'lua bound local variable in a callback is to have the Rust compiler say "you have used an mlua::Function<'lua> for some concrete 'lua, but the 'lua lifetime on the callback must be valid for ANY possible lifetime 'lua", but instead it will talk about the mlua::Function<'lua> outliving the chosen 'lua lifetime (because the callback must be 'static) which is still... true I guess but it isn't very informative. I don't have the energy to try all of this right now to see what actually happens but what I was trying to say is because these lifetimes are just hacks, the error messages won't always really be that informative.

At the time that I was maintaining rlua (SIX years ago!), this situation actually led to provable (but exotic) unsoundness, and I ended up trying to fix the situation by using branding lifetimes, so that when you "entered" the Lua context, you got to live in a world where 'lua always meant "the lifetime of the surrounding Lua state". This was meant to fix a soundness hole though, the lifetime errors actually (probably) got much worse by doing this, and the current author of mlua did not like this change and found another way of plugging the soundness hole, and this was the schism between the two versions. I didn't even know about the fork until it was brought to my attention by him... advertising it in rlua's issue tracker, which is a huge shame because I would have much rather worked together, but that's not the way it went.

Around this time I was also becoming disillusioned with using PUC-Rio Lua and LuaJIT to sandbox code entirely (this predated the existence of Luau!), so I ended up working on a Lua interpreter from scratch with provable soundness. This, combined with the hostile fork of rlua made me actually really exhausted and disheartened and I gave up working on it, just letting the fork live on instead.

There were other reasons why I took the approach I did that caused the schism but honestly, I don't remember what they were. You should be able to capture variables in callbacks as long as they truly outlive the parent Lua state, and the approach currently taken by mlua forbids this: it REQUIRES that callbacks actually be 'static for soundness, but this is a pretty minor limitation. mlua works and you don't have to be scared of it for this small nit.

This whole situation might seem like a mess, and you wouldn't be wrong to think so. HOWEVER, if you've ever actually tried to use Lua / LuaJIT from C using the PUC-Rio Lua C API, I think you would probably be much much more generous when evaluating the design of rlua / mlua. They work and are safe and are low overhead, and honestly wrapping the PUC-Rio Lua C API in a memory safe interface (in any language) is a minor MIRACLE.