There's some weird stuff going on. If I don't do a "RESET" right before going into pairing mode, then the pairing process behaves weird and doesn't always work. I'm not sure if the code version you've got is doing that step correctly. I think it should have been, but I'm not certain. I've got an update to the code which changes a few things around in terms of where certain things are getting reset, and changes the reset timings. Maybe that will help.

There are also some minor bug fixes I made in other spots but I don't think those should have affected your situation either, based on looking at your output.

I also added your PIN confirmation "OK" message into the table just in case.

In any case, get the latest code from GitHub and see if it improves things - Probably not, but worth a try.

PS: In your "hand-typed" example of the pairing process, there was a thing where you got a "PAIR <bt:address> OK" message but you didn't respond with a CALL statement to connect A2DP so I'm not sure that hand-typed example was valid. Here's an example of my latest pairing process (it's preceded by some new timings for resets and such) so here's what a successful one looks like, though my output doesn't need the PIN confirmations.

--> INQUIRY 30
INQUIRY_PARTIAL 0c:e0:e4:6c:75:68 240404
------------------------------------
Pairing with device address:
0c:e0:e4:6c:75:68
------------------------------------
--> PAIR 0c:e0:e4:6c:75:68
INQUIRY 1
INQUIRY 0c:e0:e4:6c:75:68 240404
PAIR 0c:e0:e4:6c:75:68 OK
--> CALL 0c:e0:e4:6c:75:68 19 A2DP
CALL 0
CONNECT 0 A2DP 19
--> CALL 0c:e0:e4:6c:75:68 17 AVRCP
CALL 1
CONNECT 1 AVRCP 17
CONNECT 2 A2DP 19
--> A2DP STREAMING START
--> CALL 0c:e0:e4:6c:75:68 17 AVRCP
AVRCP 1 GET_CAPABILITIES 2
--> AVRCP RSP
A2DP STREAMING START 0
--> A2DP STREAMING START
Empeg state...................................PLAYING >
AUDIO ROUTE 0 A2DP LEFT RIGHT
Detected: Pairing Mode is Complete.
--> SET CONTROL RECONNECT 600 0 0 7 0 A2DP A2DP AVRCP
STORECONFIG
CALL 3
_________________________
Tony Fabris