You didn't specify which of the mentioned context menus you are interested in.
Well, I did - I asked for testing the context menu not the the context menu for internal associations.
Anyway - all I would like to have confirmed is that my setting does NOT generate an Open item in the top of the normal Windows context menu (Right-click, Shift+F10 or the Windows keyboard context menu button). We've already established that my setting does generate an Open item in the internal context menu - I don't dispute that.
By the way, I found one unpleasant thing with your settings: when writing Filter№=*.7z;*.7zip, an empty AnyName.7zip opens with an external program by pressiing Enter.
Hmm. not here - is that when you press enter on a .7z file or a .7zip file - or both?
It could be because we might have different settings in the [PackerPlugins] section - what are your accoiations for 7z and 7zip in that section?
Do you have a global Windows association for .7zip (I don't, because the 7zip program does not offer to associate .7zip files.
And what are the results?
I did not test the speed - I tested whether the internal unpacker OR Total7zip is used when searching the content of .7z files. I did that by renaming 7zip's 7z.dll file, which gives me an error message when searching for conten - which shows me that TC uses 7zip (via the plugin) and not the internal unpacker. So if Total7zip is installed in TC, the question of which method is the fastest is academic, since the unpacking with the plugin is always used. As I wrote: there is NO "Use internal un-7Z if possible" option in TC
In other words - If you have Total7zip configured as a packer plugin for .7z files - then you must not think that you get any speed benefits from the internal 7z unpacker when searching content, because the internal unpacker is not used under that circumstance.