Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it)

Created attachment 171231 [details]
odt file to demonstrate the bug

The sample document 'test.odt' contains many occurrences of "Error: Reference source not found" because it is an excerpt of a much larger file. This is immaterial to the problem at hand.

First try:
At any position in the document, I want to insert a reference to section 2.1.3.
Hit: Insert > Cross-reference
Type: Numbered Paragraphs
Insert reference to: Number (no context)
Selection:  2.1.3

Result:
The list below the selection field contains 11 (pseudo-)hits. Only the first one is correct.  The next two lines are paragraphs that contain a reference to section 2.1.3. Should not be listed.
The following lines show headings whose number includes the sequence 2.1.3. Should not be listed.


Second try:
At any position in the document, I want to insert a reference to section 1.1.2.
Hit: Insert > Cross-reference
Type: Numbered Paragraphs
Insert reference to: Number (no context)
Selection:  1.1.2

Result: A single target is shown. Correct.
However, the cursor should be in the list field, marking the target found, so that it suffices for me to hit 'Insert'.

(In reply to Christian Lehmann from comment #2)
> Type: Numbered Paragraphs
Please choose "Headings" instead

Numbered paragraphs is every paragraph with a (numbered) list

> However, the cursor should be in the list field, marking the target found,
> so that it suffices for me to hit 'Insert'.
LO displays result from the moment you start typing. So for me it's expected, that Searching filed is still active.

Does this solve your problem?
=> NEEDINFO

On the one hand, I find it pleasant to receive advice how I can circumvent problems that I encounter. On the other hand, they sometimes tend to downplay the existence of a real bug.

1) I could, of course, choose 'Headings' as Type whenever I want to refer to a section. However, equally often I want to refer to a numbered paragraph which is not a heading. I would then have to select the Type at every given instance, which amounts to as much work as the target selection which I complained about in the first place.
Even in the Headings list, headings are shown which I am not looking for. E.g., always using the sample file I provided and having selected Type 'Headings', type "2.1.1" in the Selection field. Beside the heading looked for, you will see another one (2.2.2.1.1) which you did not look for (if you were searching it, you would type "2.2.2." etc.)
Needless to say, the problem I reported is the same if you reference some object which is not a heading. E.g., start typing "e28" in the Selection, and you will see a paragraph in the list that does not belong there.

2) As to your comment
"LO displays result from the moment you start typing. So for me it's expected, that Searching filed is still active."
we may have a misunderstanding. Select Type "Headings" and, in the Selection field, type "2.1.2.1". This identifies a single target. In the list field, this should automatically be highlighted (as it used to be the case in earlier LO versions). Instead, the cursor remains in the Selection field.

If I understand correctly, Christian Lehmann wants the "Selection" input field, where user types something to filter the results, to only take numbers into account, not the text of the numbered paragraph? It would be absolutely wrong for most of the users, who may want to type the text and find the corresponding item, and only makes sense for users who somehow know all their numbers in a heavily numbered document (well, I hardly imagine many people who know by heart all the numbers in a document with hundreds of numbered paragraphs, while I easily know people who may reasonably remember some part of text in the item they need).

(In reply to Christian Lehmann from comment #5)
> Select Type "Headings" and, in the Selection
> field, type "2.1.2.1". This identifies a single target. In the list field,
> this should automatically be highlighted (as it used to be the case in
> earlier LO versions). Instead, the cursor remains in the Selection field.

I confirm that in Version: 6.2.0.3 (x64)
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

typing '2' in the Selection makes the top element on the filtered list to be selected,

while starting from Version: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

typing '2' makes the resulting list to *not* have any selection.

I don't know if this was intentional, or some accidental breakage from, say, welding work. Marking bibisectrequest *for this aspect only*.

(In reply to Mike Kaganski from comment #7)
> If I understand correctly, Christian Lehmann wants the "Selection" input
> field, where user types something to filter the results, to only take
> numbers into account, not the text of the numbered paragraph? It would be
> absolutely wrong for most of the users, who may want to type the text and
> find the corresponding item, and only makes sense for users who somehow know
> all their numbers in a heavily numbered document (well, I hardly imagine
> many people who know by heart all the numbers in a document with hundreds of
> numbered paragraphs, while I easily know people who may reasonably remember
> some part of text in the item they need).

This is a misunderstanding.
1) If I want to refer to the object numbered 'X', then I type 'X' in the selection field and I only want to see that exact paragraph which is numbered 'X', and not dozens of paragraphs which happen to contain the expression 'X'.

2) The question of how I know that it is X that I want to refer to is a different one. If it is a heading, then my method is to look at the Navigator. Searching for a word or string that is part of the heading would be inefficient since that string may occur dozens of times in numbered paragraphs of all sorts.

However, if you want to offer the user alternative ways of finding the paragraph he wants to refer to, then we are not talking about Types of reference targets (that is what the dialog field is called), but about search strategies. You may then wish to offer:
a) Search by number [where 'number' means 'paragraph/heading/footnote etc. number]
b) Search by content.

(In reply to Christian Lehmann from comment #9)
> This is a misunderstanding.
> 1) If I want to refer to the object numbered 'X', then I type 'X' in the
> selection field and I only want to see that exact paragraph which is
> numbered 'X', and not dozens of paragraphs which happen to contain the
> expression 'X'.

Heh, no. This was not a misunderstanding on *my* part, but you substitute a discussion of "what is best for most" with your personal preference. Quite valid as an enhancement request, no problem in that.

> However, if you want to offer the user alternative ways of finding the
> paragraph he wants to refer to, then we are not talking about Types of
> reference targets (that is what the dialog field is called), but about
> search strategies. You may then wish to offer:
> a) Search by number [where 'number' means 'paragraph/heading/footnote etc.
> number]
> b) Search by content.

So your proposal seems to be "allow me to search by number only, in addition to the already existing method of searching by matching in any place of paragraph text". I agree that would be a valid enhancement (though not trivial, since Writer's link provider only gives strings, not structure internally - but that's an implementation detail that user does not have to think about), unless a simple "match from the start of the paragraph text" would suffice.

The reference to a numbered target has the same number as its target, otherwise the reader would hardly be able to follow it up. Since the target is identified by the reference, it is a natural user strategy to use its number in the selection field in order to pin it down. This is not a "personal preference" of mine, but has been standard in earlier versions of LO.

It is true that in my former post, the word 'I' was used to refer to the user. I will not repeat this mistake. It is not a fruitful communication strategy to personalize an exchange whose object is the functionality of LO. As long as there is sufficient evidence that a certain behavior of LO would be useful for a set of users, the question of whether the reporter or the developer have a personal preference for it is of little importance.

Now as to the technical aspect: It is true that in the Numbering Styles, Writer allows for Numbering alignment not only at the left, but also at the right side and even centered. So as long as the link provider does not identify the "number" of a numbered element (where, in LO jargon, a "number" is anything used to label a paragraph), it is true that the enhancement proposed would initially only work for numbers in initial position, as you say. (Users numbering mathematical or logical formulas at the page margin would be disadvantaged by that.)

(In reply to Christian Lehmann from comment #11)
> This is not a "personal preference" of mine, but has been standard in
> earlier versions of LO.

No, I have checked in all 10 major versions starting from v. 5.2 (where the selection box was introduced [1]). and it was always the same: it searched the entered text anywhere in the text of paragraph. E.g., entering "3.2" would bring 13 results, including "2. final infinitival: ch. 2.1.3.2." and "2.2.2.1.3.2. Frustrated action construction".

Furthermore, as I mentioned above, it is incorrect to imply that the preference to use numbers in the search is universal; in writing, the numbering is automatic, and user often does not even know which number one of the point might have at any given time, because of added or removed or restructured points above.

> As long as there is sufficient evidence that a certain behavior of LO would
> be useful for a set of users, the question of whether the reporter or the
> developer have a personal preference for it is of little importance.

Your proposal was re-worded at the end of comment 10 to follow that idea :-)

> Now as to the technical aspect: It is true that in the Numbering Styles,
> Writer allows for Numbering alignment not only at the left, but also at the
> right side and even centered. So as long as the link provider does not
> identify the "number" of a numbered element (where, in LO jargon, a "number"
> is anything used to label a paragraph), it is true that the enhancement
> proposed would initially only work for numbers in initial position, as you
> say. (Users numbering mathematical or logical formulas at the page margin
> would be disadvantaged by that.)

Yes.

[1] https://wiki.documentfoundation.org/ReleaseNotes/5.2#Selection_Filter_in_Cross_Reference_Tab

(In reply to Mike Kaganski from comment #12)
> (In reply to Christian Lehmann from comment #11)
> > This is not a "personal preference" of mine, but has been standard in
> > earlier versions of LO.
> 
> No, I have checked in all 10 major versions starting from v. 5.2 (where the
> selection box was introduced [1]). and it was always the same: 

Okay, then that was out of unreliable memory. Then please just take into account the user who uses the Navigator to identify the targets for references to sections.

(In reply to Christian Lehmann from comment #13)
> (In reply to Mike Kaganski from comment #12)
> > (In reply to Christian Lehmann from comment #11)
> > > This is not a "personal preference" of mine, but has been standard in
> > > earlier versions of LO.
> > 
> > No, I have checked in all 10 major versions starting from v. 5.2 (where the
> > selection box was introduced [1]). and it was always the same: 
> 
> Okay, then that was out of unreliable memory. Then please just take into
> account the user who uses the Navigator to identify the targets for
> references to sections.

Then please decide what to do with this bug, taking into account that this bug must continue with only one of the two different issues:

1. A regression (or was it deliberate decision?) that selection in the list disappears as soon as initially selected item gets filtered out (this is why I marked this bibisectrequest in comment 8);
2. An enhancement request to allow limiting filtering to numbers only.

Please keep this bug only for one of the two (and update title, pointing to a comment that provides an updated summary), and please file the other separately.

So summarizing the regression:
In the dialog for insertion of a cross-reference, the user has typed in the Selection field enough text to reduce the list of possible targets to one. In this moment, the target for the reference should be highlighted so that it suffices for the user to press the OK button.

The enhancement proposed is now deferred to Bug 141777.

(In reply to Christian Lehmann from comment #15)
> So summarizing the regression:
> In the dialog for insertion of a cross-reference, the user has typed in the
> Selection field enough text to reduce the list of possible targets to one.
> In this moment, the target for the reference should be highlighted so that
> it suffices for the user to press the OK button.

Mike confirmed this bug in comment 8
=> NEW

Closely related to this bug:
Produce the following situation: In the Selection field of the Cross-reference dialog, you have entered enough text to produce a list of possible targets in the field below it.
Now press TAB to jump to the first entry of this field. This should now be highlighted. It is not, so you are misled to the impression that TAB did nothing.

Comment 18 is a real bug. It persists in the most recent versions of LO.
Comment 15 is an enhancement. It has not been taken care of, either.
They are treated here in one bug report because they obviously concern the same user action and could be remedied on one go.