The picking of plural form #0 is hard-coded for singular strings

[jaanise]

If a translation with plural forms exist, but a simple (without count) message is requested, the plural form with index 0 is returned regardless of the MO file's Plural-Forms definition.

For example, if there is a PO file with the following Plural-Forms:

"Plural-Forms: nplurals=3; plural=n%10==0||( n%100 >= 11 && n%100<=19)? 0 :(n%10==1 && n%100!=11 ? 1 : 2);\n"

(You can see that one item would be in plural form ID=1, not ID=0.)

And this translation entry:

msgid "Product"
msgid_plural "Products"
msgstr[0] "Prod 0,10,11"
msgstr[1] "Prod 1,21,31"
msgstr[2] "Prod 2,3,4"

And you have this PHP code:

<?php
  esc_html_e('Product', 'my_payment');
  echo _n('Product', 'Product', 2,'my_payment');
  echo _n('Product', 'Product', 1,'my_payment');
?>

You will get this output:

Prod 0,10,11
Prod 2,3,4
Prod 1,21,31

As you can see, the first message is incorrectly selected for count 1.
The following ones are correctly selected for counts 2 and 1.

The selection of the hardcoded plural form ID=0 happens here: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/pomo/translations.php?rev=54469#L108

If a not-counted message is requested and the available translation turns out to be count-dependable, translate should probably either forward the call to translate_plural passing count 1, or return the untranslated fallback or an empty string (with a notice) if this is considered as a non-existing translation.

Although asking for a not-counted string but having count-dependable translations is not a correct situation in itself, it can easily occur also due sloppy programming in third party themes or plugins, or maybe occur during changes to translation files or translatable strings.