anchor.diff:      .build();
   bucket.replaceConfiguration(newConfiguration, TokensInheritanceStrategy.AS_IS);
   ----
  -It is obvious that a simple strategy - copying tokens by bandwidth index will not work well in this case, because it highly depends on order in which bandwidths were mentioned in new and previous configuration.
  +It is obvious that a simple strategy - copying tokens by bandwidth index will not work well in this case, because it highly depends on the order in which bandwidths were mentioned in the new and previous configuration.
   
   ==== Taking control over replacement process via bandwidth identifiers
  -Instead of inventing the backward magic Bucket4j provides to you ability to deap control of this process by specifying identifiers for bandwidth,
  -so in case of multiple bandwidth configuration replacement code can copy available tokens by bandwidth ID. So it is better to rewrite code above as following:
  +Instead of inventing the backward magic Bucket4j provides you the ability to keep control this process by specifying identifiers for bandwidth,
  +so in case of multiple bandwidth configuration replacement codes can copy available tokens by bandwidth ID. So it is better to rewrite the code above as follows:
   [source, java]
   ----
   Bucket bucket = Bucket.builder()
  
positive.code: [[configuration-replacement]]
  === On-the-fly configuration replacement
  As previously mentioned in the definition for <<bucket-bonfiguration>> it is an immutable object.
  It is not possible to add, remove or change the limits for already created configuration, however, you can replace configuration of bucket via creating new configuration instance and calling `bucket.replaceConfiguration(newConfiguration, tokensInheritanceStrategy)`.
  
  ==== Why configuration replacement is not trivial?
  1. The first problem of configuration replacement is making decision on how to propagate available tokens from a bucket with a previous configuration to the bucket with a new configuration. If you don't care about previous the bucket state then use `TokensInheritanceStrategy.RESET`. But it becomes a tricky problem when we expect that previous consumption(that has not been compensated by refill yet) should take effect on the bucket with new configuration. In this case you need to make a choice between:
  * <<tokens-inheritance-strategy-proportionally, TokensInheritanceStrategy.PROPORTIONALLY>>
  * <<tokens-inheritance-strategy-as-is, TokensInheritanceStrategy.AS_IS>>
  * <<tokens-inheritance-strategy-additive, TokensInheritanceStrategy.ADDITIVE>>
  
  2. There is another problem when you are choosing <<tokens-inheritance-strategy-proportionally, PROPORTIONALLY>>, <<tokens-inheritance-strategy-as-is, AS_IS>> or <<tokens-inheritance-strategy-additive, ADDITIVE>> or <<tokens-inheritance-strategy-as-is, AS_IS>>  and a bucket has more than one bandwidth. For example how does replaceConfiguration implementation bind bandwidths to each other in the following example?
  [source, java]
  ----
  Bucket bucket = Bucket.builder()
  
negative.code: 
  ** *Example 2:* imagine bandwidth that was created by `Bandwidth.classic(100, Refill.gready(10, Duration.ofMinutes(1)))`. +
  +
  At the moment of config replacement, it was 40 available tokens. +
  +
  After replacing this bandwidth by following `Bandwidth.classic(20, Refill.gready(10, Duration.ofMinutes(1))))`,
  and after replacement we will have 20 available tokens.
  