Okay thanks, see my comments below.
So for the set up. The filter is in a custom search view, which is displayed in an archive page generated with BB, and displayed through an HTML module calling the custom view.
Got it, that sounds very similar to what I assumed. You will be able to use wpv_filter_query effectively in this setup.
1: the multi-select tool isn’t the feel of the search we want...Hence why we want 3 separate select filters for the services option.
Okay I understand. My concern is that the system isn't designed to support multiple separate inputs like this for a single post relationship, and there is no public JavaScript API for search inputs. That means the custom multiple inputs design and implementation isn't supported here in the forums, and for the most part you'll be on your own to figure it out. It also means that some features of custom search Views will be lost - most importantly the "show only available options for each input" feature that limits the options in each field based on the selections in other fields. It means that you'll have to show all the options for each input field, which means Users will be able to make filter selections that may lead to "No results found" frequently.
If you plan to try implementing this custom filter system, I suggest you start out with a more default setup during development to confirm the results are what you expect to see. I'll be able to continue assisting you in this scenario, since the filtering system is more standard. Once the filtered results accuracy is confirmed, you can begin replacing the defaults with your own custom individual filters. I would start out by commenting out any wpv_filter_query code, commenting out any wpv_filter_register_url_parameters_for_posts code, deleting the current post relationship Query Filter, and then deleting the existing front-end post relationship controls (i.e. all of the wpv-control-post-relationship shortcodes and everything inside them). I would also turn off the option to "show only available options for inputs" in the View editor screen (In the Custom Search panel choose "Let me choose individual settings manually"). That feature will produce unexpected results when the search form includes custom filters, so it's best to go ahead and disable it now. Then I would insert one post relationship filter control for the Psych Therapy Formats relationship in the Search and Pagination editor. If you start by adding the filter in the Search and Pagination editor, the system will produce the corresponding post relationship Query Filter automatically, configured to respond to the proper URL params. Use the multi-select input filter to test the View's results when combined with custom field and taxonomy filter selections.
I don't think the wpv_filter_register_url_parameters_for_posts filter is necessary here. In the other ticket, this filter is used to tell the system to expect some URL parameters that were not registered in Query Filters. But in your case, I expect you will not be adding any unexpected URL parameters. The post relationship Query Filter will have the correct URL params registered when you create the multiple select field I mentioned earlier. You will be able to see how the system expects to see those selected post IDs reflected in the URL parameters during testing with the default multi-select field. You should aim to replicate that expected URL param pattern when you implement custom filters, rather than trying to implement something fully custom here with new URL params, in my opinion. Piggy-back off the expected URL param structure instead.
2 the desired effect of all filters is to AND all queried filters options, so as more filters are selected, the resulting list shortens to only contain results with all filtered criteria.
Okay I see, let's try to get the multiple select post relationship filter implemented first, then we can use the Toolset Views Debug panel to see how everything is tied together in the resulting query. Then we can discuss using wpv_filter_query to adjust "OR"s to "AND"s where possible.
You can turn on the Views debug panel in Toolset > Settings > Front-end Content, then reload the page on the front-end of the site. You may need to temporarily disable your popup blocker or whitelist this site to see the debug popup appear.
3 I have changed the taxonomy filter to respond to the URL parameter.
Okay great.