Electronic – Firmware design for OBD2 – available PIDs request to ECU

According to many documentations, we can request a vehicle ECU to respond with the PIDs it supports. Link.My question is in the end.

I have designed an OBD2 scanner using STM32 and CAN. And it works flawlessly when I use the broadcast request ID (0x7DF) and request for individual PIDs (like RPM, Speed etc). But in this case, if multiple ECUs support a particular PID then my scanner will receive multiple responses for a single request. And so I decided to choose an ECU (not the broadcast ID). For this approach, we need to know the supported PIDs in an ECU and so I use 0x00 in Mode 1 (refer link).

Testing with emulator
This request when tested with an OBD2 emulator I was receiving an expected OBD2 frame. In which the data[0] is the msg-type [idicating if it's a CAN single frame, can consecutive frame or of any other type] data[1] is the byte that differentiates between PID response or DTC response. Data[2] is the requested PID value. And finally, the rest is the actual data bytes. Eg: A PID request 0x0c (RPM) has 2 bytes returned and so will have data2 and data4.
And in my case I requested for PID 0x00 Mode 1 and got Data[3:6]. Because this was an emulator every PID was supported by the ECU.
Bench testing my logic with the emulator worked.Received data:
Testing in a car
When I tested this same code in a car the response I got was not in accordance with what I received while testing. I tested for two cases:
1. Requesting a single ECU (0x7E0) for its supported PIDs
2. Using a broadcast request (0x7DF)

In case 1
The response I received:


I can't understand what each of the bytes represents.

In case 2


Here the data received seems correct, except the fact that data[0] and data[1] is repeated. But the rest is correct, I checked the supported PIDs using a scanner I bought.

My questions
1. Am I only supposed to request for available PID using a broadcast request ID?
2. Why was the response from ECU 1 not in standard to other ODB2 frames?
3. If you have any experience or know of any project in which an OBD scanner was designed, could you share the link?

EDIT/PROGRESS
The above test was done for Maruti Suzuki Swift. Just a while back I tested the same code in a Hyundai Accent and I received the same response as seen in "case 2", i.e. I tried using broadcast and tried communication to the ECU directly, which resulted in a similar frame as seen in case 2 picture.
But still, I'm receiving two bytes with data 16 instead of a single byte with data 6. Any idea why there might be an extra byte?

I'm not sure if I'm asking the right questions.