On exit from a beatlooproll, the play position is supposed to jump to where it would have been if the loop had not been activated. Currently though, in order to get this behaviour, you have to specifically enable and disable the bealooproll using beatlooproll_X_activate. If you call reloop_exit, then the beatlooproll behaves like a normal beatloop, and just keeps playing from where it was in the loop when the loop exits.
To get beatlooproll behaviour, you have to do this:
//activate the loop
engine.setValue(group, "beatlooproll_"+looplen+"_activate", 1);
//deactivate the loop
engine.setValue(group, "beatlooproll_"+looplen+"_activate", 0);
...this is a bit of a pain - first, it's not consistent with beatloops - since beatloop_X_enabled also works for beatlooprolls (which is good), I assumed that reloop_exit would also work for beatlooprolls, and it took me a while and a bit of experimentation to figure out that I had to exit using the activate function. Second, it's a pain in scripts, because you have to keep track of which specific length of beatlooproll is enabled in order to specifically disable that length of beatlooproll using "beatlooproll_X_activate". Third, I would think this would make it pretty much impossible for straight midi-learn mappings (ie: mappings without any scripting) to use beatlooprolls at all, since they'd have to hard code in the specific beatlooproll lengths to deactivate them.
If it's difficult to make reloop_exit work for both, then Mixxx should at least provide a looproll_exit function or something, so you don't have to keep track of the length of the currently active beatlooproll in order to disable it.
One possible solution to this would be to make beatloops and beatlooprolls the same thing until the loop exits (ie: user starts loop, Mixxx tracks the resume position in case the user wants to make this a beatlooproll, and then the user calls either reloop_exit or beatlooproll_exit depending on what behaviour they want.) This might be a better implementation, since the user wouldn't have to make up their mind until they're ready to exit the loop.
I think this is a bug not a wishlist :). We should fix this in 1.12.