In the SPH_RANKER_HIT structure in the query_pos field, positions of service words are taken into account.

Nobody has claimed this yet.

In the SPH_RANKER_HIT structure in the query_pos field, positions of service words are taken into account.

For example, there is a query:
SELECT id, WEIGHT() FROM myindex WHERE MATCH(’“22К 734”~10|“4 1 208”~10’) OPTION ranker=my_ranker(’’);

When calling the plugin function XXX_update (), in the query_pos field for words 22K 734, there will be positions 1 and 2, respectively. And for the word '4' the position will be 4. This happened due to the fact that position 3 was assigned to the word '10', which is a service word and is the operand of the proximity operator.

The same effect can be observed if you call CALL KEYWORDS.
For example, CALL KEYWORDS (‘22К 734”~10|“4 1 208”~10’, ‘myindex’);
±-----±----------±-----------+
| qpos | tokenized | normalized |
±-----±----------±-----------+
| 1 | 22к | 22к |
| 2 | 734 | 734 |
| 3 | 10 | 10 |
| 4 | 4 | 4 |
| 5 | 1 | 1 |
| 6 | 208 | 208 |
| 7 | 10 | 10 |
±-----±----------±-----------+

This issue was discussed(question 3):
https://forum.manticoresearch.com/t/topic/637/2

Start by reproducing the reported queries with ranker=my_ranker and CALL KEYWORDS, then trace how query_pos is populated for SPH_RANKER_HIT. Compare positions for service words such as the proximity operand 10 with ordinary terms. Done means service words no longer consume positions in query_pos or CALL KEYWORDS output.

Written by the indexing model from the issue text.