I would manually unwrap the texture coordinates in the pixel shader and use tex2Dgrad (or equivalent function) for fetching the data.
Do you have any idea what that entails? 64 unwrappings requires 64 specific start-end coordinates and the 64 manual wrapping calculations associated with each.
This approach has been used for more than a decade by tons of engines;
Then why this:
I am simply looking for an existing bleeding-aware tool to pack textures.
So many engines for so long, why doesn’t such a tool already exist?
Would it be wise for you to make your own solution? Not sure, because:
I want to support 64 textures and I want to dynamically fetch different textures per-pixel based on a material mask.
You never identified texture filtering as your main problem, and instead blamed texture wrapping.
If you’re already comparing your solution to an existing one’s, the bleeding is not caused by wrapping (it would be though), it is caused by bilinear-filtering.
I’m not sure you can make a better tool than one that exists because I am not sure you understand what is causing the artifacts you are seeing.