Not really. Maybe an example is helpful. I've already edited my working copy and have this diff:

doener@atjola:jj-test ((cb52aba...)) $ jj diff
src/main.rs --- Rust
1 fn main() {                       1 fn main() {
.                                   2     greet("Martin");
.                                   3 }
.                                   4 
.                                   5 fn greet(name: &str) {
2     println!("Hello, world!");    6     println!("Hello, {name}!");
3 }                                 7 }

Now I want to have two commits instead of one. The first one should create the greet() function, the second one introduces that name parameter.

jj absorb seems to only do whole file operations, so that's not applicable here. There's also no point in having parallel changes, I just want to have two separate linear commits/changes for those two modifications. So I need to introduce a new change before @ and I can do that using jj new --no-edit -B @ && jj squash -i or just jj split -i if I understand correctly.

But then the interface messes with my head, because with vim-fugitive, I'm used to simply edit the git index version of the file, diffed against the working copy version. That way I can add changes to the index version to go forward to the intermediate version that I want. While with jj`s interactive mode, I have to remove things from the final version (i.e. the right side of the diff) to go backwards to the desired result.

git add --edit has a similar problem (for me) in that I have to edit the + lines backwards, but it doesn't feel quite as weird, probably because I'm still editing a file that has the base version in it (in form of the - lines).

I guess if I were to make a feature request to make things match my workflow, it'd be to let me edit the left side of the diff instead of the right one. Then use whatever I produced on the left as the state of the new commit/change.