Does vyos not support multiple OSPF processes?
Can you be a little more verbose in what you’re trying to achieve? 
The Vyos router is connected on two links, which are in different OSPF processes. The routing information in the two processes is isolated.
Do you mean OSPF areas? Or something else? I still don’t understand fully what you mean I’m sorry!
===== OSPF Process 1 Configuration =====
router ospf 1
router-id 1.1.1.1
network 10.0.0.0 0.0.0.255 area 0
! ===== OSPF Process 2 Configuration =====
router ospf 2
router-id 2.2.2.2
network 192.168.1.0 0.0.0.255 area 0
Configure multiple processes like Cisco routers
Right, gotcha.
No, VyOS does not currently support this - I say this to the best of my knowledge, I could very well be wrong.
You achieve similar with VRFs howver.
FRR, the underlying OSPF process does support it, but that’s not exposed in VyOS.
Do I smell a feature request coming up?
Having the process being VRF aware is probably a good step forward and since FRR already supports this it “should” be a fairly small task to update the vyos-config stuff related to this.
Also be able to have multiple processes for process isolation would probably be the next step along with network namespaces or such as a greater segmentation but Im guessing this would take some more effort to complete?
The thing here is that with other NOSes such as Arista EOS when you create a VRF in the backend they will also at the same time create a network namespace (or similar) for full isolation. But VyOS currently doesnt seem to do this. Most likely since VRF in Linux world is ONLY about the routing table.
That is where you have a L1/L2 isolation with other NOSes when setting up a VRF the Linux way of doing VRF means that two VRFs in Linux can still attack each other at L1/L2 layer which would be blocked once network namespaces (or similar) is setup along with the VRF.
FRR does indeed support this, and it would be an excellent addition. FRR Docs
This is distinctly different from VRF’s in that you would be running entirely separate OSPF Processes within the same RIB/VRF. You then need to redistribute routes between them if required for your topology. There are some interesting scenarios when this feature can be useful or desired. Particularly when you need to run OSPF with another business unit, and BGP is not an option. (Mainframes, Firewalls managed by another team, etc).
I agree, however, that VRFs would work better for most cases, except you would need to route-leak.