CKAN Version: 1.6.1-0-g2e91715
Operating System: W10/64
The issue you are experiencing: search for "FAR/ferram ..." is empty for KSP1.1.2
How to recreate this issue: select all, search name 'ferram'
CKAN error codes (if applicable): -
the registry.json is valid, has all FAR versions, up to 3:0.15.6.3
if I switch ckan to a KSP 1.1.0 install, I can find/install the correct 3:0.15.6.2
if I switch to a 1.1.2 install, FAR does not show up anywhere, in no list/search.
it does not autodetect it, either (offers it as suggested install though)
I have not pinned down other mods, but I suspect others may be affected.

I have the same issue with RealFuels currently (CKAN-meta cae944b306f8e142c12911a6d0ce07e87a95f92b). It seems that is due to the GUI not showing modules which are available but missing dependencies. If I modify the Incompatible() in Registry.cs I can get them to show up, though this is most likely not the proper way (Since they are compatible, just missing a dependency at the moment).
What do people think of renaming the current "Compatible" category to "Available" and introducing a new "Compatible" category which would show these mods?
Edit: and also have them show in "All"
showing up in "all" permanently would be a good start :)
@RichardLake Sound like a fine suggestion to me.
Duplicate of https://github.com/KSP-CKAN/CKAN/issues/1529, will close that one as this has a more solution-oriented discussion.
Another mod that is not showing up at all is Sum Dum Heavy Industries (SDHI), which according to it's main forum page is indexed by ckan. There is the SDHI - Shared Assets mod.
Especially with the recent KSP patches this has become a very prevalent issue. Raising priority.
btw, the example of FAR is no longer valid, as the "parent" MFI mod has been updated.
Finding examples won't be a challenge. In the course of working on an unrelated issue I noted CKAN has 1406 unique identifiers in the metadata (as of https://github.com/KSP-CKAN/CKAN-meta/commit/8c9ebae012b958b09b47358776d28c8655f67e65) and the client only lists 1178 in the "All" filter .
Lets not forget problems where it goes MOD A depends MOD B and there both available and correct. However MOD B depends on MOD C which is not. See #1646
FASA suffers from this on 1.3.1 currently, and it may in fact belong in Compatible depending on the status of the TextureReplacer dependency. Strongly agreed about the All filter suggestion.
Here's where GUI generates the list:
var gui_mods = new HashSet<GUIMod>(registry.Available(versionCriteria)
.Select(m => new GUIMod(m, registry, versionCriteria)));
gui_mods.UnionWith(registry.Incompatible(versionCriteria)
.Select(m => new GUIMod(m, registry, versionCriteria)));
var installed = registry.InstalledModules
.Select(m => new GUIMod(m.Module, registry, versionCriteria));
Available has special code for checking dependencies, but Incompatible does not. Mods in this situation are excluded from Available because of their missing dependency, but also don't fall in Incompatible because they technically match the version, and that's all that's checked. So they're just left out of the list completely.
Most helpful comment
What do people think of renaming the current "Compatible" category to "Available" and introducing a new "Compatible" category which would show these mods?
Edit: and also have them show in "All"