I confirm too for 2.8. Oddly, it only happens for the modifier, not the tool (oddly because the code for the core bevel is the same). And the second bevel doesn't have to have 0.5 width -- any width will show the problem as long as the first one had width 0.5. I will investigate further.

OK, this was mysterious, but I understand the problem now. It is that vertex groups are getting mixed up in a way that is likely unexpected to users: there are weights associated with each vertex in a group and the bevel modifier considers each vertex to be part of the bevel if the weight is >= 0.5.

The problem is that when new vertices are made, their custom data is interpolated between the custom data of all of the vertices in the face that they are created in. What is happening in the example blend is that when you do a bevel on vertex group Bevel1 with width 0.5 then the interpolation causes the new end vertices to have 0.5 for weight in Bevel1 group and also 0.5 for weight in Bevel2 group (which wasn't involved in the first bevel, but is adjacent so the interpolation causes Bevel2 group to "leak over" onto new adjacent vertices. This means that the second bevel modifier, on group Bevel2, now operates on more vertices than the user intended when setting up the groups Bevel1 and Bevel2. When you use width 0.4999 the interpolated weight for Bevel2 group on the new vertices is just shy of the magic 0.5 value I use to decide whether or not to have those vertices participate in the bevel.

The root problem is that we are using vertex group weights to indicate membership in a set instead of boolean values. If they were boolean values, we wouldn't even be trying to interpolate the values in the face, but rather they would be set from the example vertex (the one that the bevel verts are being created around) and all would be well. I wonder if this problem shows up elsewhere in Blender where vertex groups are using for membership semantics?

I am not sure how to fix this and would appreciate comments from users and other devs. Here are some possibilities:

1. Have bevel go back and "fix" the interpolated values for the newly created vertices so that the entire weight comes just from the vertex that the new vertices are created around. This is a bit messy, needing more code, and might not be the right solution if we want to fix the general problem of "weights shouldn't be interpolated if they are being used for membership semantics". Also, what if the weights are being meaningfully used for something other than group membership, so that interpolation semantics are what is needed? Right now, there is no way for bevel to know which groups should be "fixed" and which should be left interpolated.

2. Make a separate kind of vertex group that is only used for membership, so has boolean values, and doesn't get interpolated. This could/should also be done for edge and face selection groups, something that has long been asked for by users. The problem here is mainly that this is a significant amount of work, probably not possible before the 2.80 release, At least, if done properly, with good UI support, documentation, tests, etc.

3. Have a bevel modifier option to be the threshold to use for deciding membership (instead of hard-coded 0.5). I doubt this really solves the problem, because if you bevel beyond 0.5 in our example case, the interpolation will actually move membership more towards adjacent vertex bevel groups and there probably won't be ways of manipulating the threshold properly to get the intended effects.

In my opinion, option 2 is the only workable one, but as I said there, kind of difficult to implement on short term.

A workaround for the particular case in the bug report would be: use Bevel1 vgroup for the first bevel limit, but instead of Bevel2 for the second, specify that group using Bevel Edge Weights = 1.0 and the weight limit method. I realize there are many similar cases for which such a workaround won't be possible, sorry. I hope we can fix the bigger problem eventually.

Added Campbell to get his opinion too on how to solve this problem with vertex groups being used for membership and interpolation.

I thought of another possible fix for bevel:

4. add an option for user to say whether or not vertex groups should ALL be treated as membership groups and therefore not interpolated. This would solve the problem that I can't tell the purpose of a group. But yucch.