Three resource-pack texture paths are flat. The mob one nests, and that is the least of it
Items, blocks and paintings live one file deep. Mobs live in a folder named after themselves — and for most mobs that folder holds several files, so a one-file override silently misses.
Overriding a texture in a resource pack means putting a PNG at the exact path the game looks in. For three of the four common kinds, that path is completely regular. For the fourth it is not, and the irregularity is worse than it first appears.
The four paths
assets/minecraft/textures/item/<name>.png
assets/minecraft/textures/block/<name>.png
assets/minecraft/textures/painting/<name>.png
assets/minecraft/textures/entity/<name>/<name>.png ← note the folder
Items, blocks and paintings are one file in a shared directory. A mob is a directory of its own, named after the mob, containing a file usually named after the mob as well. So the zombie texture is entity/zombie/zombie.png, not entity/zombie.png.
Note also that mobs live under entity/, not mob/ — the folder is named for the code concept rather than the game one.
The real problem is that a mob often is not one file
The nesting is easy to remember once you have seen it. The thing that actually breaks overrides is what else is in that folder.
Replacing a mob with a single PNG is confirmed to work for exactly ten:
zombie · skeleton · creeper · sheep · spider · enderman · wolf · witch · blaze · villager
Everything else may keep its textures in a different subfolder, or spread them across several files — baby variants, tamed variants, colour variants. A horse is not one image. A cat is not one image. Replacing one file in those cases changes one state of the mob and leaves the rest untouched, which reads in game as "my pack only half-applied".
That is the failure mode worth internalising: a wrong path shows no texture change at all, but an incomplete path set shows a partial one — and the second is much harder to diagnose, because the pack demonstrably works.
Priority is highest-first, which is not what a zip suggests
When packs are merged, the pack listed first wins path conflicts. Index 0 is the highest priority.
This is worth stating plainly because it inverts the mental model people bring from layering files, where the last thing written wins. Here the first pack in the list is the one whose version of item/diamond_sword.png survives; everything below it only fills in paths the ones above did not claim.
Two details about pack identity
pack.png is the icon and lives at the zip root, not under assets/. It is squared to 64 × 64 — a non-square image gets resized rather than letterboxed, so an icon designed at 16:9 will come out distorted rather than padded.
Colour codes in the pack name are literal text. The § characters go into pack.mcmeta exactly as typed and Minecraft renders them at display time: §a green, §c red, §b aqua, §e yellow, §d pink, §l bold, §r reset. There is no escaping step and no JSON text component involved — the raw section sign in a plain string is the whole mechanism.