Network Analytics not working

Unfortunately, I have no way to contact Azure support, so I hope this is a proper place to describe the issue.

When you enable Network Analytics for VNET flow logs, Azure provisions a DCR/DCE in the resource group where your Log Analytics Workspaces resides. Problem is, when you delete those two, any subsequent VNET flow logs with NWTA enabled deploys succeed, but not working. By not working I mean, the flow logs are correctly kept pushing into the storage account, but no data injected into the LAW.

After hours of troubleshooting it, I found out that you have to provision a new LAW with a different name (delete/recreate wouldn't work), so the first VNET flow log deployed to that LAW successfully provisions new DCR/DCE. I was able to reproduce the behavior three times in a row.

I know, the documentation has this:

Data collection rule and data collection endpoint resources are created and managed by traffic analytics. If you perform any operation on these resources, traffic analytics may not function as expected.

but that's not enough, you know.

0. First of all, I'd like all this scripted, so I don't have to create exemptions for my tagging/naming policies.
1. Next, how do I recover my existing LAW from that issue? There is no way I can ask my org to provision a new Sentinel LAW, right?
2. Then, can this whole thing be configured with AMPLS? I couldn't find if this is even doable in the documentation, not to mention a working example.

p.s.
I tried to script the DCR/DCE the same way as Azure does it, but that had no effect. I guess there is some internal thing going on under the hood
p.p.s.
Sorry about the rant, but the experience feels like a punishment

Start by reproducing the reported sequence: delete the DCR/DCE, deploy VNET flow logs with Network Analytics enabled, and inspect delivery to the Log Analytics Workspace. Review the existing guidance on DCR/DCE management and the questions about recovery, policy exemptions, and AMPLS. Done should document a supported recovery path and configuration guidance, or clearly identify what Azure support must address.