I've used hand rolled pseudo ORMs before.
I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense.
That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.
There is usually a feature that no one thought about and then you have to make modifications to the custom ORM and you get an even bigger mess.
I wouldn't say what I built was a better ORM. But I would 100% say it's a better solution to the problem I faced.
It didn't get in the way of writing SQL, but it did reduce the boilerplate and repetitive gruntwork.
"Issues" - no, it was a function call deep and incredibly clear and close to what was happening.
Is your pseudo ORM as well documented as a commonly used ORM? Can I google (or search your wiki) for common issues?