@Hackwar Could you check this? Would be much appreciated. Thanks in advance.

Additional Observations

I continue to probe the code for clues about the failure of tags-only searches. In my debugging I have noticed some anomalies but couldn't be sure that what I was seeing wasn't due to operator error or some misconfiguration of my debugger.

As a cross-check, I enabled the System Debug in Administrator > System > Global Configuration > System tab > Debug Settings > Debug System. Set to Yes. Save.

Then I ran the same search mentioned above. At the bottom of the No Results Found page in the Joomla! Debug Console section, I opened the Database Queries panel. 47 Queries Logged and 18 duplicate found.

Let's use this query as an example. (For this listing the actual database prefix has been replaced with #_.)

SELECT l.link_id,m.weight AS ordering
  FROM `#__finder_links` AS l
  INNER JOIN `#__finder_taxonomy_map` AS t0
  ON t0.link_id = l.link_id
  INNER JOIN `#__finder_taxonomy_map` AS t1
  ON t1.link_id = l.link_id
  INNER JOIN `#__finder_taxonomy_map` AS t2
  ON t2.link_id = l.link_id
  INNER JOIN `#__finder_taxonomy_map` AS t3
  ON t3.link_id = l.link_id
  INNER JOIN `#__finder_links_terms4` AS m
  ON m.link_id = l.link_id
  WHERE l.access IN (1,1)
  AND l.state = 1
  AND l.published = 1
  AND (l.publish_start_date = '0000-00-00 00:00:00' OR l.publish_start_date <= '2020-03-28 01:41:00')
  AND (l.publish_end_date = '0000-00-00 00:00:00' OR l.publish_end_date >= '2020-03-28 01:41:00')
  AND t0.node_id IN (645)
  AND t1.node_id IN (647,669)
  AND t2.node_id IN (649)
  AND t3.node_id IN (653,654,655,656,657,658,660,661,663,664,665,666,667,668,670,671,672,673,674,675)
  AND m.term_id IN (54280)
  ORDER BY m.weight DESC
  LIMIT 1000

The Joomla Debugger reports Rows returned: 0. In my Visual Studio Code debugger, at line 1720 of /libraries/joomla/database/driver/mysqli.php, the $array has 24 elements of type stdClass that are otherwise empty.

If I run the MySQL query above manually in PHPMyAdmin, I receive 24 populated rows with branches of types Type, Author, Language and Category as expected.

After running the database query again in PHPMyAdmin, I find that it also returns an empty set. The last line of my Additional Observations comment above is wrong. I'll continue to examine the query.

So... I think I have a bad information for you: The tags for an article are not indexed. Tags are indexed as seperate entries, but there is no connection to the articles itself.

I have reexamined my database tables in PHPMyAdmin to verify that my original analysis still appears to be valid.

For the particular search in my example above, I specified a tag of C2 Single Equation Models. In the #__tags database table, I find that record has an ID of 3 and the published value is 1, checked_out is 0, level is 1, created_time is 2020-02-04 23:31:41, modified_time is 2020-02-04 23:33:27, publish_up is 2020-02-04 23:31:41, publish_down is 2020-02-04 23:31:41. The alias and path for that tag record are both c2-single-equation-models.

Next I move to the #__contentitem_tag_map database table. There are 74 entries with a tag_id of 3. All records in that database table have a type_alias of com_content.article. There are various values of core_content_id and content_item_id. The tag_date fields have values before today's date. The type_id for all records is 1.

Take one record of the #__contentitem_tag_map database table. It has a core_content_id of 3 and a content_item_id of 77.

Now I open the #__content database table and search for an ID of 77. In the database record for that article, I see that the state is 1, created is 2012-10-11 13:41:20, checked_out_time is 0000-00-00 00:00:00, publish_up is 2012-10-11 13:41:20, publish_down is 0000-00-00 00:00:00, access is 1.

I open the selected article in the Joomla Administrator article manager and in the right column of the content tab, confirm that the C2 Single Equation Models tag appears in the Tags section. Furthermore I can open the article itself in the front end of the Website.

The Smart Search Indexer runs to completion with no reported errors. The article with an ID of 77 appears in the Smart Search Indexed Content table with a status of Published. In Smart Search Content Maps, the article's category is also Published.

The configuration of the Smart Search Filter for the Tags-Only search remains as stated in section B of the original report above.

Note that the failure of Tags-Only Smart Searches is identical for all 67 searches not just this one tag.

What additional tests shall I run?
What additional connections are required to make the search produce results?

B. Then in Administrator > Components > Smart Search > Search Filters, I created a published filter for tags only.
B1. In Search by Author, all authors are selected.
B2. In Search by Category, the relevant categories are selected.
B3. In Search by Language, All is selected.
B4. In Search by Type, only Tags is selected.
The title of this filter is Expertise Smart Search - Tags Only and its ID is 5.

Again, I think you are misunderstand something here. If you select something in the filter, that means that a search result has to contain all selected taxonomies. If you select only Tags for Types and then select the whole list of categories, it can't display anything, because tags don't have categories. But your filter says "Display everything that is a tag and has one of these categories."

As I wrote earlier, the index does not contain any information about the tags in connection to other content items. We have a finder plugin for tags, but that adds the tags as an item to search for, like an article or a newsfeed. It does not add the connection between an article and its tags. For that, the article indexing plugin would have to add the tags as taxonomies to the article in the index and that is currently not happening. And it isn't happening, because the tagging system is very difficult to handle right now.

Apparently what I was trying to do is not possible, at least in that old version of Joomla. Perhaps this issue should now be closed.

Closing as stated above. Thanks for reporting back.