I actually noticed this issue with Beta 3 (upgrading straight from v10.1.2) but I forgot to report it.

===

I have a trigger to move an application to a specific screen that doesn't work. Here's how I setup the filter:

TRIGGER BOX

Trigger Enabled (obviously )
Event: Window Created
Frequency: Always
Stop processing triggers if this one matches: Enabled (I tried also disabling it, but nothing changed)

MATCH CONDITIONS BOX

Process Filename: The app's executable "fmd.exe" (see download link below)
Delay before checking match conditions (MS): 0

ACTIONS BOX

Move Window to Selected Monitor: #2
Maximize Window: -

====

The app's window remains where it opens (on monitor #1). Even the DF taskbar's option (on monitor #2) with the enabled option Force application to start on the same monitor as Taskbar has never worked with it (which is why I added the trigger).

The application is the same one I mentioned in this previous discussion: https://www.displayfusion.com/Discussions/View/displayfusion-101-beta-3-now-available/?ID=ec71555f-4c81-4c07-a52b-ac46b0b6ab50#8

The version currently being used is the latest one: fmd_2.0.32.0_x86_64-win64.7z

===

One thing I noticed, is that with Beta 3 the window was still moved to monitor #2 after 40-50 seconds. However, with Beta 4 the window is moved even later (right now in my last test it took 4+ minutes).

Also, I have to manually move it by clicking the application's titlebar and manually drag it to monitor #2. Neither the shortcut registered to move the window to the next monitor (CTRL+WIN+X) nor the titlebar's button "Move Window to Next Monitor" work.

In case you've already read the discussion, I edited the first post and added some observation and further info at the bottom of it.

@Owen: Yes, it works just fine with v10.1.2.

EDIT: In case it makes a difference, I'm using Windows 10.

Downloading it now. I'll let you know.

It takes a few seconds, but it seems to work after a quick test.

Must better than 1+ minutes anyway.