One thing worth ruling out first: an --up script cannot do this, because the device has to exist before openvpn.exe opens it, and --up only runs after the interface is up. So the scripted route has to sit outside OpenVPN, around the launch.
tapctl.exe, which ships in C:\Program Files\OpenVPN\bin and is what you are already using by hand, is scriptable, so a wrapper around openvpn.exe gives you the create/use/destroy lifecycle you want:
tapctl create --hwid wintun --name "OpenVPN Wintun tmp"
"C:\Program Files\OpenVPN\bin\openvpn.exe" --config client.ovpn --windows-driver wintun --dev-node "OpenVPN Wintun tmp"
tapctl delete "OpenVPN Wintun tmp"
The delete only runs once openvpn.exe exits, so the adapter lives exactly as long as the session. tapctl list will show you the names and GUIDs if you want the script to be idempotent and clean up leftovers from a crash.
Two constraints that decide whether this is actually usable for you:
Creating an adapter needs administrator rights. If you normally connect through openvpn-gui plus the interactive service, the GUI itself is not elevated, so the create step fails in that path. Practical workaround is a scheduled task registered with highest privileges that the unelevated user can trigger, otherwise you are back to a pre-created adapter.
Every newly created adapter gets a new instance GUID, so Windows sees a brand new network each time: a new entry under the NetworkList profiles, fresh Public/Private categorisation, and any firewall rule or route metric scoped to a specific interface stops matching. Creation also costs a couple of seconds and logs a driver install each time. If you have per-interface firewall rules, this is the part that will bite you, not the OpenVPN side.
That is really the argument for the pool approach: create N adapters once with deterministic names, then pin each profile with --dev-node so the mapping stays stable, instead of churning devices per connection. It costs you nothing at runtime and keeps interface-scoped configuration valid.
One question that changes the answer: how are you launching, GUI with the interactive service, plain openvpn.exe, or as a Windows service, and do you need more than one tunnel up at the same time? If it is a single tunnel launched by a script you control, the wrapper is fine; if it is the GUI with several profiles, the fixed pool is the more workable route.
