Why does a hobby reader module miss some tags?
Three causes, in order of frequency: the chip does not implement the protocol that tag speaks, the small antenna on the board leaves little margin, and the library on top exposes a fraction of what the chip can do. The tag is rarely the problem.
The protocol the chip never had
Start with the datasheet of the chip on the board, not with the module's product page. A chip built for ISO/IEC 14443 A will not answer an ISO/IEC 15693 tag, and no antenna, no wiring and no library changes that. A multiprotocol part says so plainly: TI's TRF7970A datasheet lists 15693, 18000-3, 14443 A and B and FeliCa, and a chip whose list is shorter is shorter in the field.
Identify the tag before accusing the module, which the chip identification page does with a phone in a minute. A module that reads three of your four tag families is behaving exactly as its datasheet says.
A small antenna and no margin
Module antennas are small, and range follows the loop. TI's antenna matching note gives a working rule for a reader antenna: expect about twice the diagonal of the antenna, which for a board the size of a few centimetres is a tap rather than a distance. The antenna size page explains why the tag's own coil matters as much.
Then there is what sits around it. The same note asks for ground planes to be kept away from the antenna traces, and a module screwed above a battery, a display or a metal plate meets the detuning every tag meets on metal. A module that reads on the bench and fails in the enclosure has not changed: its antenna has.
The library above the chip
Between your sketch and the chip sits code that exposes a subset of the registers and commands the datasheet documents. A module that cannot read a tag type its chip supports is often a library that never implemented it, and the way to know is to compare the datasheet's command list with what the library offers.
This site names no library. It is enough to say that the chip is the reference and the library is an implementation of part of it, and that a project whose requirement sits outside that part has to reach the chip directly.
The order to test in
Test the protocol first, with a tag of each family and a phone as the control: a tag your phone reads and your module does not is a module problem, and a tag neither reads is a tag problem.
Test the antenna second, out of the enclosure and away from metal, at the distance the rule of thumb predicts rather than at the distance you hoped for.
Test the library last, by sending one command the datasheet documents and reading the answer. It is the slowest of the three and the one that produces a definitive answer, which is why it comes after the two that often end the search.
Frequently asked questions
My module reads one tag and not another of the same size. Why?
They are probably different tag types. The chip implements the protocols its datasheet lists, and the two tags do not speak the same one.
Would a bigger antenna fix it?
Only if the failure is range. A protocol the chip does not implement stays unreadable at any distance.
Why does it work on the bench and fail in the case?
Metal and ground planes near the antenna move its tuning. Test in the enclosure, since that is where it has to work.
Is the tag at fault?
Rarely. Check it with a phone first: a tag a phone reads is a tag, and the module is the part that has to be explained.