Looks good to me!
I'd personally go for storing the order of jobs internally (e.g in a BTreeMap with a counter), but storing Instants in frozenjobs works very well, and it's much less overkill.
I just think it's worth having tests for this bugfix tho.

Sorry for the insane amount of amends, I should have been more careful.

I'm not very familiar with BTreeMap, but I'm guessing that'd mean faster reorders at the cost of more memory and doing more allocations. Either way, I doubt it'd make a difference, as almost no one will have enough jobs for it to matter.

waiting for tests

I've been looking into adding in the tests, but there's a problem. Let me explain:

#[test]
fn job_unfreeze_works() {
    let actual = nu!(r#"
        nu -c "kill -s 19 $nu.pid; echo meep"
        job unfreeze
    "#);

    assert!(actual.out.ends_with("meep"));
    assert_eq!(actual.err, "");
}

This is one of the tests I've written. 19 corresponds to SIGSTOP, which does the same thing as Ctrl+Z. In theory this should work, but it instead hangs and leaves the spawned nushell instance as a zombie process. But when I try the same lines on my terminal, it works perfectly:

$ nu -c "kill -s 19 $nu.pid; echo meep"; job unfreeze

Job 1 is frozen
meep

Of course, nu!() macro uses --commands to send in the commands. Adding another -c resulted in this:

$ nu -c 'nu -c "kill -s 19 $nu.pid; echo meep"; job unfreeze'
Error: nu::shell::io::uncategorized_error

  × I/O error
  ╰─▶   × Failed to unfreeze foreground process

   ╭────
 1 │ crates/nu-command/src/experimental/job_unfreeze.rs:148:21
   · ────────────────────────────┬────────────────────────────
   ·                             ╰── Uncategorized error
   ╰────

Error: nu::shell::non_zero_exit_code

  × External command had a non-zero exit code
   ╭─[entry #4:1:1]
 1 │ nu -c 'nu -c "kill -s 19 $nu.pid; echo meep"; job unfreeze'
   · ─┬
   ·  ╰── exited with code 1
   ╰────

The issue is that -c leads the shell to not be interactive. But the function setting the group ID for the main process exits early on non-interactive shells. And yes -i fixes this, but there are issues with that too.

I don't really know what the right approach would be in this case.

Edit: I used sh instead since that seems to work.

@peachey2k2 can we get these conflicts resolved and move forward?

Sorry for not checking formatting. Also I commented out the tests so beware of that.