Duplicated HelpFiles (about_) prevent Get-Help to

Problem: I have two about_psreadline help topics: about_psreadline and about_PSReadLine. Get-Help cmdlet cannot display information on any of them. Get-Help about_psreadline just displays a table with two mentioned help files.

Question: How to deal with duplicated HelpFiles? Could/Should one of them be removed?

Powershell version: 6.1.3; I also checked PSModulePath and the only path containing PSReadline is C:\program files\powershell\6\Modules

Whenever Get-Help shows a list of topics rather than the requested topic's content - despite having provided a specific topic's name - you can call .ToString() on the individual list items to show their content; e.g., to show the 1st item's content:

(Get-Help about_PSReadLine)[0].ToString()

To show them all, one directly after the other:

Get-Help about_PSReadLine | ForEach-Object ToString

As you've discovered, renaming or removing duplicate files solves the problem persistently; see below for how to find them.

However, doing so shouldn't be necessary, as the behavior observed is likely a bug - see this GitHub issue; details below.

^{Applies as of PowerShell Core 6.2.0-rc.1}

The problem stems from multiple versions of a given conceptual help topic being available, due to:

multiple versions of the underlying PowerShell module being installed...
and/or - in the case of in-box modules (modules that ship with PowerShell) - preinstalled help files continuing to be available even after newer versions of in-box modules have been installed.
- As of Windows PowerShell v5.1 / PowerShell Core 6.2.0, this is only an option for a subset of the in-box modules (PSReadLine, Microsoft.PowerShell.Archive, PackageManagement, PowerShellGet).

Note:

The multiple-version problem seems to affect only conceptual help topics (about_*), which are implemented as individual *.help.txt files.
- By contrast, the help topics for a given module's cmdlets are typically delivered as part of a single MAML file (a *-help.xml file whose name contains the module name); only ever one version of such topics is considered current and therefore its content is directly displayed (no listing of multiple versions).
- In light of that, the differing - and obscure - behavior with multiple conceptual help topics is likely a bug, especially given that you cannot tell what versions the listed items are associated with; on a related note, for non-conceptual topics, there is currently no way to view the other versions' help, which appears to be a design limitation.
Help topics can be delivered as part of a given module or, in the case of in-box modules, in subfolders named for the language (e.g., en-US) in the same folder as the PowerShell executable.
At least in PowerShell Core, on-demand installed modules seemingly can also place topics in Help folders that are sibling folders of other folders listed in $env:PSModulePath; in these Help folders, conceptual help topics can seemingly be present both at the top-level (in language-specific folders) and in subfolders named for modules (in language-specific folders) - I'm unclear on the logic behind this.

I'm unclear on the exact precedence rules / listing order among the multiple versions of a given help topic; in Windows PowerShell, a conceptual help topic version installed alongside powershell.exe seems to come first, but that doesn't appear to be true in PowerShell Core.

Unfortunately, inspecting the list items' properties does not reveal their source file, only their source file's length (size in bytes).

However, you can locate help files independently: The following helper function (a more fully-featured version of which can be downloaded from this Gist) builds on your own command for locating all help files for a given conceptual help topic or module name:

function Get-HelpFile($fileNamePart) { 
  # Note the use of Split-Path -Parent, because help files can be in sibling
  # folders of $env:PSModulePath folders.
  Split-Path -Parent ($env:PSModulePath -split [IO.Path]::PathSeparator) | 
      Get-ChildItem -File -Recurse -Filter *$fileNamePart* |
        Where-Object Name -match '(?:\.help\.txt|-help.xml)$'
}

# Find help source files whose name contains 'about_psreadline'
Get-HelpFile about_psreadline

You can pass any substring contained in help file names, such as module names, e.g. PSReadLine, but note that this won't necessarily show all help files associated with that module, given that conceptual help topics don't necessarily contain the name of the module they're associated with.
Also, some module names aren't reflected in their help file names, notably module Microsoft.PowerShell.Core (help file name is System.Management.Automation.dll-Help.xml) and Microsoft.PowerShell.Management (help file name is Microsoft.PowerShell.Commands.Management.dll-Help.xml).

If you pipe the above command to | Select FullName, Length, it will list the file size in bytes (property .Length) alongside the full path, which can be correlated with the sizes reported by, e.g., Get-Help about_PSReadLine | Select Length, so as to infer the order in which the topics are being listed.