<datalist> behavior(s) are inconsistent and unhelpful when options are prefiltered

What is the issue with the HTML Standard?

[First, my apologies for clumping what is probably a handful of complaints about browser-specific issues into a single issue here, but I believe the underlying issue is that the spec here isn't very clear on how datalist elements are actually supposed to work. Or, if it is, the behavior is less-than-helpful. More than anything, I'm hoping someone here can suggest the best way to proceed with this.]

One of the more common use cases for datalist is to provide users typing into an <input type="text" /> element a list of options pulled from a search API. For example, I have a project (npmgraph.js.org) that uses this NPM search endpoint to construct a DOM structure like this:

<input type="text" id="search-field" list="search-results" value="mi">

<datalist id="search-results">
  <option value="mi">The simplest and most obvious way to use multiple inheritance in Javascript that I could think of.</option>
  <option value="confiance-test">Test de fiabilidad y contenido estadistico</option>
  <option value="@activity-design/mi-design">组件库</option>
  <option value="@cheap-glitch/mi-cron">A microscopic parser for standard cron expressions.</option>
</datalist>

CodePen example demonstrating this markup.

Expected Behavior

In the case described above, the options in datalist come from an authoritative search API - i.e. ALL of the options are known to match the, "mi" string the user has entered into the input field. For that reason, we expect all options to be presented to the user. Something like this:

IMPORTANT: The 2nd option, "confiance-test" does not contain the input text value ("mi") but should still be included.

Actual Behavior

No production browsers handle this case well. In all cases, one or more options are omitted, presumably on the basis that the input text, "mi", isn't contained in the option 'value' (or inner-content, depending on implementation). While this isn't all that surprising, it is not desirable. Again, the options here represent a known set of results from an API that has taken care applying the desired search criteria.

Browser	Screenshot	Comment
Edge		Omits non-matching options
Firefox		Omits non-matching options. Does not display inner-content
Safari		Omits non-matching options
Chrome		Omits non-matching options
Safari (iOS)		Omits non-matching options. Does not display inner-content.
Chrome (Android)		Only shows first option?

Proposal(s)

First and foremost, it would be nice if there were a way to specify that the contents of the datalist were canonical. I.e. that the client should not attempt to filter the options in any way and, instead, just display as many as is feasible. Some possible ways of implementing this:

<!-- "canonical" attribute" -->
<input type="text" canonical list="search-results" />

<!-- "unfiltered:" list name prefix" -->
<input type="text" list="unfiltered:search-results" />

I'm sure there are others that readers more familiar with the HTML spec / process can suggest.

Second, (and maybe there's already an effort to standardize this?) clients should show both the value and the inner-content of the options, ideally in a manner that is css-style-able.

Start with the HTML Standard's datalist and text input behavior, then compare the linked CodePen example and the browser cases described here. Determine whether the proposal should define canonical or unfiltered option handling and how option values and inner content are presented. A concrete, agreed specification change and interoperability expectations are needed before implementation.