I don't recall seeing that type of signal before. It will take me a bit more effort than usual to figure out the structure and I don't have time for that today.

I think you provided enough samples to allow deducing the structure. It does not use the common menthods of encoding bits into bursts, so a couple samples would not have been enough.

It has fairly ordinary overall structure and timing. The fact that it is unusual in the way meaning is encoded in that timing shouldn't matter at all to a learning remote that just reproduces the timing. It should be very easy timing to reproduce well.

This encoding system is more sensitive to distortion than typical encoding systems, but not a lot more, not enough to explain the "not too dependable when imported into URC". Maybe there is some bug in that import process. I don't think I will have time to investigate that possibility (import to URC, then learn to Pronto or JP1 remote or CaptureIR and see how different the result is from the original Pronto Hex). You could try that if you're curious.

This encoding system should be hurt more than most by the typical distortion caused by low batteries in the sending remote. But I don't even know whether URC remotes generate that kind of distortion. Any simple remote will generate the typical distortion when its batteries are too low. But a more complex remote would more likely malfunction or abort (or maybe warn) in a more complete manner (not send the signal at all rather than send it distorted by bad batteries). So that would say low batteries would hurt all protocols equally in that complex remote.

There's always the chance the published Pronto Hex is seriously wrong and you'll find the signals different when you learn from the original remote.