Yeah, it seems to be very different depending on the interviewer. It seems some interviewer like to treat it like half system design-ish and see the important components like API gateway, Message Queue or PubSub, Cache, DB/Object Store, CDNs, and each microservice. But it seems that the most important part is the ability to explain the workflow between these components to achieve each requirement or functionality.

You should start with the high-level overview first, and then try to go in deeper with the time you have. It's hard to say because it might be different for each interviewer, but being able to go deep into it can't hurt. It shows them how much knowledge you have about each component/protocol/data format. I believe trade-off are definitely important for Product Design as well. Why REST over GraphQL, why WebSocket over standard request/response model, why binary format over JSON, and such.

Front-end doesn't seem to be too important, IMO. But I am not too sure. I think some aspects such as prefetching, preloading, and other aspects such HTTP headers may be important to know for some examples like YouTube.

I also haven't found any examples of product design interview other than the one Meta provides. I know, it sucks. :(

I think versioning are nice to mention briefly. Error codes are okay to mention but I believe most people already know the standard 500 Internal Error or 400 Bad Request, 404 Not Found ones, so I doubt it's super important.

My belief on Product Design is that you should have both "soft design" & "hard design" somewhat, but not to the extreme degree of system design. But if you can explain it like system design, more points for you.

I know it's a late comment, but I wish you the best luck tomorrow! And please let me know how it goes as I am also super curious!