Why not just avoid the issue altogether? Managing additional windows is a pain. In most cases there are easier and better ways to do what most people want.
We have a Leave Sheet that is tied to a calendar with portals that display related leave requests records. The leave request records must be managed by manager who can approve, deny, cancel or partially approve the leave. leave is sorted into 5 different categories. The leave sheet does not display all the decision making information (there's too much to show on one page) but the managers want to be able to see the leave sheet as they make changes to it via the leave management page.
I really can't see an alternative other than adding the approve, deny, cancel and partially appprove buttons directly to each record which would crowed the page.
The window resize issue is a pain. It's not one that I've been able to eliminate, but I have been able to minimize it. You can open the new window, then select the original window and use Move/Resize window to set its dimensions to the maximum possible. (Use get ( ScreenHeight ) and get ( ScreenWidth ) to get your current monitor dimensions.)
Then, when the Pseudo-Dialog is closed, use a script to maximize windows. What you get is a "twitch" as the background window shrinks slightly when the Pseudo-Dialog pops up and then another "twitch" when it maximizes on close of the Pseudo-dialog. Not the prefect result, but works for my solutions. I also include code that tests for the platform and only do this for windows systems.
In your script, I'd simplfy things by using Go To Related Record to open the new window, specify its layout and display the portal record clicked all in one step.
To make this window "modal" so your users don't 'lose' it back behind the original window, put the script in an infinite loop with allow user abort[off]. Buttons and scripts that include Halt Script either as a script step or a button option, can be used to close the Pseudo-dialog and escape the infinite loop.
You can see some example scripts for handling Pseudo-Dialogs in the Known Bugs List Database. You are welcome to open up and study those scripts to see how this can all fit together.
Note 1: if you don't maximize windows, the resize issue does not occur.
Note 2: It's easy to get trapped in that infinite loop and have to force quit fileMaker or use the script debugger (FileMaker Advanced Only) to get out of that loop. It's safer to leave out the allow user abort script step until you test your scripts and make sure everything else is working correctly.
This new window layout, neat and clutter-free as it doubtless is... why not just take the manager to another layout, with exactly that design?
I used to do just that in older versions when such a Pseudo-dialog was not possible. The result was really awkward in many cases--especially if your script has to change to layout 1 to get info from the user then switch to layout 2 to display the results after processing the info from Layout 1. I had layouts that were blank except for two or three formatted data entry fields.
In my opinion, a small dialog for capturing a few crucial pieces of info, but using the full scope of options for the design of a FileMaker layout makes for a very convenient and familiar user interface. Often, the user needs the 'context' of the background window when entering data (search criteria for example) into the pseudo-dialog.