Yes - if the dialog was not being assigned that Form's HWND as its owner window (in Win32 API terms, not VCL terms). A dialog can never appear behind its owner window, it stays on top of the owner. By default, VCL dialog components typically use the HWND of the currently active TForm that has focus, otherwise they may use the MainForm's HWND, or even the TApplication's hidden HWND. So, if the owner of the dialog is not the Form you are expecting, that would cause the symptom you describe.
The main thing to know about TaskMessageDlg() is that it is just a wrapper. Internally, it performs a few system checks to decide whether to use the Win32 TaskDialogIndirect() function vs the VCL's own TMessageForm class.
So, for instance, if you wanted to work around this issue, and you knew your app was always running on systems that support TaskDialogs, you could use the VCL's TTaskDialog component (or even TaskDialogIndirect() directly), explicitly passing it your intended Form's HWND as the dialog owner, eg:
procedure TMyForm.DoSomething;
begin
// TaskMessageDlg(...);
TaskDialog1.Title := ...;
TaskDialog1.Text := ...;
...
TaskDialog1.Execute(Self.Handle);
end;
procedure TMyForm.DoSomething;
var
config: TASKDIALOGCONFIG;
begin
// TaskMessageDlg(...);
config.cbSize := sizeof(config);
config.hwndParent := Self.Handle;
config.pszWindowTitle := ...;
config.pszMainInstruction := ...;
config.pszContent := ...;
...
TaskDialogIndirect(config, ...);
end;