Yes, it's implemented in part 1-4 of my patch queue in bug 961871.
Here's how it works -but is subject to change at any time-:
- The following are all in untransformed CSS pixel unit. This makes
the implementation *much* simpler and more predicable for web
- We look at the scrollport area (the bounds of the visible area) of
the document that will-change is used within to set the budget. This
is multiplied by some constant which is currently 3 times but I'll
open a discussion to change that to perhaps as high as 9 times within
the Firefox 36 time-frame.
- When a frame is seen that uses will-change the area of the frame is
added to the budget for that document.
- If the total usage for that document is in budget then all
will-change optimizations are performed. Otherwise none are performed.
 We need to decide the will-change budget at the end of the display
list phase which is too early to know the will-change costs in layer
pixel which happens in the follow layer building phase. Using CSS
pixels prevents us from requiring a second pass in some cases to
properly implement the will-change budget in terms of layer pixels.
 If layer pixel were used an author could lose their will-change
optimizations because we decided to re-rasterize a scaled layer at a
higher resolution. This happens seemingly unpredictably from an
author' point of view.