A common dependent form layout pattern will modify selection items once the parent selection is made. This is especially important if you intend to allow a user to change the filter type after creating one; the needed fields will change depending on the edits made.
Example: Creating a new filter will only show the Name and Filter type fields, perhaps with a disabled default state saying "select filter type". Once a selection is made, new fields show below, with the appropriate additional selections, Function and Types / Value where appropriate.
If the design for the single- or multi-select requires a larger width, then perhaps widen the overall modal to fit.
The Block model filter, however, represents an interesting challenge. Are the table columns and rows predefined, or do you need to allow for adding in new columns and rows? If so, the modal size constraints given may not provide all the needed space to include such UX elements. If they are predefined, why not just have them as more text-inputs in the existing design, perhaps with a separated label to show they are grouped together, and separate from the generic filter form fields?
I would encourage NOT using a dynamic horizontal-width Modal, because expanding sideways will introduce greater visual disparity and change. If shown as screen-centered, once expanded w/ additional content, the original form fields will have shifted left, moving content under where the user had their focus, (requiring mentally recalculating where the mouse has to click next). If you add items vertically, (while keeping currently clicked element exactly where it was), the user's focus is in the same place and they can peripherally notice the next selection is where there was change. The mouse moves only to the next line to keep adding data. If you have a modal that hides the additional horizontal content, but displays in such a way that the original form fields stay put, you'll have an off-center modal 50-75% of the time. (assuming even use of all filter types; unlikely)
