In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default.
So I'm keeping support for it all while want to be able to provide best user experience.
Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users.
Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage.
So, the backwards compatibility is a good issue Michael pointed out.
While processing of multiple "r" parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r=" alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and use only usual "r=".
This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating "r" - an array and a string. I don't have a solution for that atm.
If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols.
And then I would also modify existing BIP72 to strictly define "r=" as "http(s)" only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter.