Greetings, I'm the staffer manning things here today and whilst I'm not really the one to answer this question "officially," I also know we don't actually have "official" rules so there's not much stopping me from taking a run at it!
It's important to remember that there's no such thing as "account"
with cryptostorm. We don't have any "accounts" (I helped write the token auth systems, so I know this better than most I suppose). There are only tokens - and hashes of tokens.
Now, I can see how there's a certain pressure to reverse backwards into "accounts" - for exactly thinks like issuing a few tokens to someone to cover several devices. This might be fine on an ad-hoc basis, but I can assure you that it's not ever going to become part of the cryptostorm data model... because I'm pretty much the one who maintains that model, so I can exercise veto power.
As to why multiple sessions per token is a Bad Idea, that's clearly more of a "pj issue" but since he's off doing long-overdue academic stuff this week (not sure that's ok to release publicly, but if he's unhappy he'll let us know) and dusting off his rusty French language skills in the process, I'll take a swipe. It's like issuing two keys to the front door of your summer cottage: convenient, yes, but also an obvious security risk. More specifically, I think there's concerns that OpenVPN could "leak" session data between concurrent logins since, in its own data model, sessions are identified by login credentials and thus two sessions on the same token are in some senses one token. This is a flavour of "MiTM" but not really - more like a Sibyl attack, as I understand it. But it's crypto gibberish to me; I do tokens.
tl;dr version is that when it comes to "accounts" as you ex-colonists say: Not. Gonna. Happen. And that's 'cause of some Security Issue that is a big deal to the security side of things. But: if someone needs a few tokens, word is that the support folks will issue them. They're good like that.
We totally get that lots of folks have multiple devices and that they want to protect them - sometimes router-based connects will do that, but other times (like smartphones) that's not going to work. And when we designed the token auth model, we had lots and lots
of talks about this issue - I know, as I had to sit through them. The veto came from the security issues of multiple concurrent sessions, and when that stuff gets put on the table around here, it trumps everything else. So we pulled back to one session = 1 token. In fact, I remember that feeding back into the pricing decisions we made - since we wanted to be sure it was affordable to buy multiple tokens since we can't do concurrent sessions.
That's all I know - more than I know, technically. If I'm misspeaking, surely someone will correct me. Eventually.