This behavior has been reported by email and confirmed by Christian Chisler, but since there are no changes in behavior of TC 9.20 beta 2, I'll report it here.

I noticed, that often after restart in history menu I have less items than in previous TC session.
Yes, after restart TC shouldn't show in history some paths, like some locantions in virtual folders that TC doesn't save because the path can't be represented by GUIDs.
But I see often removes just several oldest paths, even if before closing TC history menu items count has less items than allowed by HistoryLen (default=26), and TC removed oldest history recodrs with normal file system paths like c:\.

Sample case:
after closing TC it's possible to get following content in wincmd.ini:

As you can see, wincmd.ini doesn't have HistoryLen parameter,
which means Total Commander has max 26 history items.
In [LeftHistory], you can see 26 records, 0...25.
Now start Total Commander with this wincmd.ini and count intems in left panel history menu:
you'll count 24!
Then, in this TC session in left panel enter to some 2 subfolders to get history menu items count 26.
Now restart TC again:
you'll see 24 items in history menu again, with oldest 2 paths from previous session being removed, although wincmd.ini will still have 0...25 records.

I don't know what's the logic behind such TC behavior, but I think that both on exit and on start, TC should check the history and remove from [LeftHistory]/[RightHistory] the items it really isn't going to show in menu, not just oldest items.
So visible history menu items count should match 0...25 records in [LeftHistory]/[RightHistory], and if such count is already have less records, TC on start/exit shouldn't then remove anything._________________Android 4.3.1 no root, kernel 08.09.2016; Vista Home Premium SP2 rus 32 bit
TC #149847 Personal licenceCuz we're all in this together, We're here to make it right

Last edited by DrShark on Sun May 13, 2018 3:12 am; edited 2 times in total

I have checked this now: What TC does is remove duplicate entries from the displayed list, so more paths can be reached with the limited length:
e:\2\3\4\5\6\7\8\9\10\11\12\13\
and
c:\
appear twice in the list.

They still remain in the internal list, so when you use Alt+Left, the directories are visited in the order stored in the ini. And when you close TC without changing anything, the list will still be saved with 26 entries._________________Author of Total Commander
http://www.ghisler.com

2ghisler(Author)
At first: for some reason with ini I posted here in a forum, even after removing trailing spaces added by browser and replacing spaces with Tab before # character (either browser copy or forum code block parsing issue) in text editor, TC shows 26 history items. The differences from my ini from email are deleted right panel-related parameters, command line history, some searches and packerplugins sections, so I don't understand why the issue can't be reproduced with ini I posted on a forum...
Anyway, please re-test with ini from email (attach HistoryRemoveBugIni.zip in email from subject Re[4]: TC's possible dirs history entries removing bug from May 1, 2018). For it TC on start shows 24 menu items.
And if you'll then enter 2 paths (e.g. go to dirs in c:\dir1\dir2\ tree; in that TC session you'll see 26 history menu items), after restart you'll get following [LeftHistory]:

(as you can see, the records paths from initial ini records 24=e:\2\3\4\5\ #1,6 and 25=e:\2\3\4\ #1,5 are removed), and for it TC will still show 24 items in menu.

If your comment is already is after a test for my email ini, then the question is why TC removes 24=e:\2\3\4\5\ #1,6 and
25=e:\2\3\4\ #1,5 on exit instead of duplicate paths you mentioned._________________Android 4.3.1 no root, kernel 08.09.2016; Vista Home Premium SP2 rus 32 bit
TC #149847 Personal licenceCuz we're all in this together, We're here to make it right

What's unexpected here:
in TC session, it didn't show the
2=e:\2\3\4\5\6\7\8\9\10\11\12\13\ #1,14
4=c:\ #0,2
items, so user could enter additional 2 paths without having items visually removed.
But after restart, user will see 24 items, and the items removed from previous TC session are:
e:\2\3\4\5\ #1,6
e:\2\3\4\ #1,5
It's more expected that on Exit TC will remove invisivble items,
e:\2\3\4\5\6\7\8\9\10\11\12\13\ #1,14
c:\ #0,2
instead of oldest paths, so all the unique paths will be available after restart.

As I wrote above, if uniqe visible items count won't be larger
than HistoryLen count, it's expected that TC won't remove the items from menu on exit.

My possible solutions to the issue:

1. Optionally, TC can use HistoryLen as a counter only for visible menu items.
Which means, [LeftHistory]/[RightHistory] may have as many items as it's required to
visually show e.g. 26 default menu items.
With such a behavior, after entering c:\dir1\dir2\ tree and restart,
TC just wouldn't delete
e:\2\3\4\5\ #1,6
e:\2\3\4\ #1,5
so on TC restart for case 2, user would see history 26 entries.

2. Optionally, you can make TC show on start also the items it currently hides.
Then, user would see all the following same paths in menu:
0=c:\
2=e:\2\3\4\5\6\7\8\9\10\11\12\13\ #1,14
3=e:\2\3\4\5\6\7\8\9\10\11\12\13\
4=c:\ #0,2
The visible items count then is 26, so after user enters
the tree c:\dir1\dir2\, the removing of oldest entries:
e:\2\3\4\5\ #1,6
e:\2\3\4\ #1,5
at least will be expected.

3. Optionally, TC can use HistoryLen only for [LeftHistory]/[RightHistory] entries count: TC should remove items it currently deletes on exit in live mode, so when user enters c:\dir1\ in our above example, TC instead of addinig it as the 25th item to the menu, it should at first immediately delete e:\2\3\4\ #1,5 record and show c:\dir1\ as menu item 24. This way, TC will show 24 items both in session and after restart, which will be more expected.

EDIT: I deleted the question about "wrong duplicates" (3= and 5= entries in LeftHistory) - they are actually different paths.

So it's clear user expects max=26 entries in menu.
In reality, TC applies HistoryLen=26 separately for the menu and for [LeftHistory]/[RightHistory] in wincmd.ini:
- while TC is running, it allows user to have up to 26 entries in menu;
- on exit, TC makes the duplicate paths invisible, but they are still considered as menu items, so TC writes the latest 26 items, including duplicates, into wincmd.ini, while other (older) items, visible or invisible, are removed.
- this also means: if TC started with a significant number duplicate items that are newest folders in history, and also several oldest paths will be unique, on that TC session will not show invisible paths, so if user before exit from TC won't reach visible items max count, but will reach total (visible+invisible) items count, TC will on exit remove oldest entries, even if they are uniqe and visible. I.e. if user has 24 newest invisible items of 25 max, and also the oldest one (26th, c:\dir1\) is uniqe and visible, and in the TC session user will only enter to some uniqe c:\dir2\ (so in the history menu one will only see 2 paths), on exit TC will remove oldest c:\dir1\ from history!

I think the behavior will be more expected if on exit TC will count the items it will actually show on next start, and save in [LeftHistory]/[RightHistory] latest max (as defined by HistoryLen) of visible items+all the needed invisible items between oldest and newest visible._________________Android 4.3.1 no root, kernel 08.09.2016; Vista Home Premium SP2 rus 32 bit
TC #149847 Personal licenceCuz we're all in this together, We're here to make it right

Total Commander behavior is much more complicated than described in Help, see above post.
Can you please consider the suggestion from second part of that post? That would make Total Commander behavior much more predictable to users not familiar with a nature of "invisible duplicate menu items" (they currently aren't even described in the Help)._________________Android 4.3.1 no root, kernel 08.09.2016; Vista Home Premium SP2 rus 32 bit
TC #149847 Personal licenceCuz we're all in this together, We're here to make it right