When a release has multiple ASINs associated to a it, it can only be queried by one.

Example release:

• https://musicbrainz.org/release/c151419a-f7d8-4be3-ae98-dd4e686afbb2 has different ASINs by region – I'm not on top of things when it comes to deciding whether the different metadata (same recording, different name for the tracks) of the non-English languages qualify, but at very least the UK and the US ASINs do differ, even though they correspond to the same MB release (with any region specific details in the release events).
• A query for one of its ASINs finds it: https://musicbrainz.org/search?query=asin%3AB06X6C79JX&type=release&limit=25&method=advanced
• A query for another does not: https://musicbrainz.org/search?query=asin%3AB06X15V4D6&type=release&limit=25&method=advanced

It appears that only one of the ASINs is placed in the database as a direct property of the release, whereas the others turn up dry.

As a workaround, instead of querying by ASIN, I've tried searching for the ASIN using the URL search, checking whether the results are actually release ASINs and following the relation back, and that works – but that's awkward code, error-prone (who knows how Amazon URIs might change), and needlessly stresses the servers (as it does full-text search over URIs in an extra request instead of a precise lookup).

The two ways to resolve this that come to my mind are:

• Resolve the ASIN query search field to a joining query
• Document tha ASIN query field to be an unreliable shortcut, and direct users (both in the API docs and in the web search when it comes up dry on an `asin:` query) to the proper way to do the search (which might be my workaround or an enhanced version thereof)

Thanks for providing this infrastucture.