Quick investigation shows the regression was introduced in https://invent.kde.org/utilities/krusader/-/merge_requests/50 or https://invent.kde.org/utilities/krusader/-/merge_requests/49 . Adding Toni.

While I fully support and cheer adding all the goodness with Undo Closing and Insert After Current options (thanks for working on this, Toni), changing the default without introducing an option to get back to the behavior that's been there for many years is a regression. Besides this, popup menu looks wrong now - there are two options "New Tab" and "Duplicate Current Tab", which do the same thing (shortcut actions have the same issue). Users will definitely consider this a bug. Moreover, the icon for the "New Tab" in popup is the same as on the New Tab button in the tab toolbar, which gives the idea that it should open a fresh tab.

I propose the following:
1. Revert "New Tab" actions to the old behavior (opening a fresh tab). Popup and shortcut bugs will be fixed with this.
2. Add an new option "Show duplicate tab button" that will reveal Duplicate Current Tab button with correct icon in the tab toolbar. We already have "Show new tab button". Users can choose (or even enable both!).
3. (Optional, just as an idea to consider) If we think the default location (= home dir) is not good, we could add an option to specify a location to open with the new tab (like Home Page in browsers).

BTW, wanted to comment on this assumption in MR-50:
> People who use Konsole, Double Commander, Total Commander or Dolphin are used to the fact
> that when they open a new tab, it starts from the same folder that they were using.
> When trying Krusader, they do not expect that new tabs start from the home folder.

This is not correct. Personally, I used to the fact that Konsole and TC are doing this, however I expect Krusader to be better. In fact, when Konsole introduced this, it was hard to rewire to the new behavior, and still sometimes I forget about this and have a "what's going on" flashes... We actually don't know what users expect as we haven't conducted any user study. So let's do it softly and don't introduce additional cognitive load with the new release.

If someone follows the development of Krusader he/she can see that there's a commit "New tabs start in the current folder and can be inserted next to the current tab or at the end", with its merge request.

As it's already explained in the aforementioned merge request :

The aforementioned programs (Konsole, Double Commander, Total Commander or Dolphin) do that, so people who use those programs are used to the fact that when they open a new tab, it starts from the same folder that they were using. When trying Krusader, they do not expect that new tabs start from the home folder. 

If the user is working on a folder, it's more frequent that the next action is going to be done in that folder or near it (a subdirectory, upper directory, etc.) instead of in the home folder. Anyway, going to the home folder is easy with a hotkey (Alt+Home) or using a Krusader button that can be enabled.

That change is not a regression since is a design decision, intentional, approved and Krusader developers, people who use the git version, and users of e.g. the [PPA of Rik Mills](https://launchpad.net/~rikmills/+archive/ubuntu/experimental/+packages) have been using that for more than a year.

Now that we are at it: removing the "CONFIRMED" status since the same one that opens a report can not be the one that confirms it, as we already know (otherwise, all would be "CONFIRMED" bugs).

(In reply to Toni Asensi Esteve from comment #2)
> If someone follows the development of Krusader he/she can see that there's a
> commit "New tabs start in the current folder and can be inserted next to the
> current tab or at the end", with its merge request.
> 
> As it's already explained in the aforementioned merge request :
> 
> The aforementioned programs (Konsole, Double Commander, Total Commander or
> Dolphin) do that, so people who use those programs are used to the fact that
> when they open a new tab, it starts from the same folder that they were
> using. When trying Krusader, they do not expect that new tabs start from the
> home folder. 
> 
This assumption is not confirmed by any user study and not considering active users that got used to the new tab opening in the home dir. For example, for me it's not the case, please read comment #1.

> If the user is working on a folder, it's more frequent that the next action
> is going to be done in that folder or near it (a subdirectory, upper
> directory, etc.) instead of in the home folder. Anyway, going to the home
> folder is easy with a hotkey (Alt+Home) or using a Krusader button that can
> be enabled.
> 
It's not more frequent for me, it's the opposite. I use Duplicate Tab (via shortcut) when I need a copy. Using two actions as you suggest is far from convenient and opening a new tab is a frequent operation.

> That change is not a regression since is a design decision, intentional,
> approved and Krusader developers, people who use the git version, and users
> of e.g. the [PPA of Rik
> Mills](https://launchpad.net/~rikmills/+archive/ubuntu/experimental/
> +packages) have been using that for more than a year.
> 
I understand it's intentional and I disagree with this intent. :)

In fact, the change was not approved per our dev process. See for yourself: https://invent.kde.org/utilities/krusader/-/merge_requests/50. One of the devs other than the author needs to approve. There is no tag change. There is no GitLab approval. Not even a comment that somebody tested it. You might have interpreted thumbs up from Yuri as an approval, however it does not count. Thumbs up means the user likes the proposal. It doesn't mean the change is reviewed or approved. In any case, with all the respect to Yuri, Yuri's role is to support the documentation, he's not acting as a developer in this project per his own choice. In the same time, this was not a simple code change. It had to be reviewed by the devs - Dave or me. I just want to make it clear regarding approval status for this and future changes. It's ok to change the dev process if you don't like it, but we should have a discussion and come to an agreement first.

As for git version users, yes, some people use this version, however it doesn't mean they like it. I know a person (not me) who reverted this change as they don't like it but want to enjoy other fixes. I use a snapshot version with the change for several months as an experiment whether I'd like it in a long run. So far, I don't. It often feels like tripping over a stone during a smooth walk.

Actually, I think we need to ask krusader user group and check who would like to see it changed in the new release without an option to go back and who'll miss it.

And there is definitely an inconsistency in the menu as I mentioned in comment #1:
> Besides this, popup menu looks wrong now - there are two options "New Tab" and "Duplicate Current Tab", 
> which do the same thing (shortcut actions have the same issue). Users will definitely consider this a bug.
> Moreover, the icon for the "New Tab" in popup is the same as on the New Tab button in the tab toolbar,
> which gives the idea that it should open a fresh tab.

And regarding the status.
> Now that we are at it: removing the "CONFIRMED" status since the same one
> that opens a report can not be the one that confirms it, as we already know
> (otherwise, all would be "CONFIRMED" bugs).

There are two ways to have a bug confirmed:
1. Multiple users report the same issue - then it's auto-confirmed.
2. A dev checks the bug and may confirm it.
This is the second case.

> New Tab actions perform a tab duplication [...] And there is definitely an inconsistency [...] 
> there are two options "New Tab" and "Duplicate Current Tab", which do the same thing [...]                            
That is not true, "Duplicate tab" always opens the duplicated tab next to the previous one, though with "new tab": that depends on the "Insert tabs after current" ("Insert new tabs after current one") setting that the user can choose. So the user can choose opening new tabs at the end of the row and still duplicate a tab next to the original one (like in web browsers).

On https://invent.kde.org/utilities/krusader/-/merge_requests?scope=all&state=merged anyone can see the upvotes, for example to "New tabs start in the current folder and can be inserted next to the current tab or at the end" . Developers of Krusader can have accepted a merge request using the means they have considered adequate in that moment ─like a comment, an upvote, etc. without being told now to go back and do it again, this time looking for a tag, click a link, etc.☹                    

Knowing that Konsole, Double Commander, Total Commander, Dolphin, (for more than a year) people who use the git version of Krusader, users of the [PPA of Rik Mills](https://launchpad.net/~rikmills/+archive/ubuntu/experimental/+packages) and other places that may exist like https://aur.archlinux.org/packages/krusader-git use that way, someone would think about a user study would be done to show that all that software is doing it incorrectly.

Writing more now about that would be repeating what is already stated there and in the merge request.

A possibly relevant merge request was started @ https://invent.kde.org/utilities/krusader/-/merge_requests/99

Git commit adc3873952047c4ec115aedd56ac50ce048fab8e by Nikita Melnichenko.
Committed on 12/09/2022 at 05:59.
Pushed by melnichenko into branch 'master'.

Fixed New Tab action behavior in tab context menu

New Tab action duplicates a tab if "New tab button duplicates a tab"
is checked, however the setting should control only the New Tab Button.
For duplicating tabs there is a separate menu item "Duplicate Current Tab".
As shortcuts are assigned to tab actions, this also fixes shortcuts.

This change restores the action behavior to the state it was in v2.7.2
and also makes it aligned with major browser behavior (Chrome, Firefox).

Along with e64a7acf it fixes the following bug:

FIXED: [ 447394 ] New Tab actions perform a tab duplication instead of opening a fresh tab

Discussion: https://invent.kde.org/utilities/krusader/-/merge_requests/99

M  +2    -2    krusader/panelmanager.cpp
M  +1    -1    krusader/panelmanager.h
M  +1    -1    krusader/paneltabbar.cpp
M  +1    -6    krusader/tabactions.cpp
M  +1    -2    krusader/tabactions.h

https://invent.kde.org/utilities/krusader/commit/adc3873952047c4ec115aedd56ac50ce048fab8e