Twelve days with status inquiries and an expedite request already filed is on the long side but not unheard of right now. A few things that sometimes help: confirm the build shows as Waiting for Review (not Missing Compliance or Metadata Rejected) and that export compliance and the App Privacy answers are complete, since an incomplete item can leave a submission idle without any message. If everything is green, you can cancel the submission and resubmit the same build, which puts it back in the queue without losing the build. It is also worth checking Resolution Center and your account email for anything marked as needing action. Keep the case numbers handy and ask for a callback through Contact Us if there is still nothing after another week.

The 4.1(a) note says the issue is "references to Minecraft", so I would search for that literally rather than only swapping assets. Check the app name, subtitle, keywords, description, screenshots, in-game text and menus, texture and sound file names, bundle name and even code comments or strings that could surface in the binary. Block-style voxel worlds can also trigger the "similar to a popular game" part even without any named reference. In your reply in App Store Connect, list exactly what you changed and why the game is distinct (own characters, quests, art direction), and attach a short gameplay video. Ask for a phone call through the Contact Us form on the developer site if the thread stays quiet, and if it does get rejected again you can file an appeal with App Review Board.

Adding one angle to the good advice above. 4.3(a) is mostly about the app looking like many others in a crowded category, and media players are one of the most crowded on iOS. The macOS store is far less saturated, which can explain the different outcome even for the same codebase. What tends to move a 4.3(a) review is showing, not telling: A short screen recording in the App Review notes (30 to 60 seconds) that goes straight to the two or three things no other player does, not the basic playback. Screenshots and description that lead with those features. Reviewers see the store listing too, and a listing that reads like a generic player reinforces the 4.3 decision. No template traces. Placeholder text, sample content or UI that matches common player templates is often what triggers the similarity flag. Then reply in the same submission thread asking which apps or elements were considered similar, and if that does not resolve it, the App Review Board appeal is the next step.

A few things worth checking, in this order. Attach the build first. Before a build is selected, the media section can show tabs for every device family. What is enforced at submission depends on the build you attach. Check what the build includes. In TestFlight, open the build. If a watchOS app or extension is listed (an old watch target, or a dependency that adds one), the Apple Watch tab is expected. Remove the target and upload a new build number. Check UIDeviceFamily in the uploaded binary, not just the project setting. A plugin, framework or generated config can add iPad (2) even when TARGETED_DEVICE_FAMILY is iPhone only. Unzipping the .ipa and reading its Info.plist settles it. On impact: if the attached build really is iPhone only with no watch app, you can leave the iPad and Watch tabs empty and still submit. If submission asks for those screenshots, the binary itself declares support for those devices, and the checks above will show why.