This version of the formula works:
fn-If(fn-Equals(Location,"A"),"View1","View2")
Maybe someone else can explain why this variation of the syntax works. I didn't see anything obviously wrong with your statement. Just tried the above variation for fun and it worked.
HOWEVER, this is only a partial victory. Please understand that as an inline function this still only fire at initial form load. Thus, here is the behavior you can expect:
1) New Mode - no value exists in the SP list Item Property of Location at the time the form is loaded, so the formula will resolve false and you will get View2.
2) Edit Mode - the value of Location will exist for the item selected in the list prior to clicking Edit. Thus, the formula will resolve correctly and as expected, View1, if editing a list item with Location A and View2, if editing a list item with any Location other than A.
Your calculated value control is returning the value of the Location in the Location CONTROL. Calculated fields do update during runtime, when there is a change on the form. However, the value of the item property does NOT change during runtime. Item property values are exchanged with the form only two times, upon initial form load (edit and display) and upon form save (new and edit).
So, think the above will work for you for edit purposes. However, if during the editing the user changes the value of Location, this will NOT change the lookup view after what was captured at initial form load.
One possible solution to your issue that I can think of:
Install two different list lookup controls on your form, one hardcoded with View1 and the other hardcoded with View2. Create a rule for each to hide the lookup you don't want, based on the Location value selected in the choice field. To avoid having both or neither lookup show on the form in New Mode, you could put a default value in the choice control, so the rules would always put one or the other lookup in place.
Good luck!