There are a number of methods that already accept/return parameters that have semantics of resource accounting (resource limits/usage amount, etc). The type of these parameters can not be changed because of compatibility reasons. This is why we have introduced additional rules that describe POA Public API policy regarding this issue.
In general, an additional method parameter of type bigint is introduced. The name of that parameter partially coincide with original one with one exception that new parameter will have '64' prefix.
In case of input parameters, an introduced bigint parameter is optional. So it is safe for the user to keep using specific methods in a usual way, transferring usual int parameters. However, if it appears that user should transfer big number, he could use bigint parameter and do not transfer int parameter at all (or leave it 0 because bigint parameter has higher priority).
POA Public API will always transfer both int and bigint output parameters that refer the same value. If it appears that the actual value does not fit the int representation, then the minimal negative or maximum positive integer would be returned in int-typed parameter (depending on actual value) and correct value will be returned in bigint-typed parameter. So it is relatively safe to keep reading int output parameters but it is better to always use their bigint analogs.
Please note that rules described in this section concern existent method parameters only. The new bigint parameters will not have any int analogs and will be named in a usual fashion (no '64' prefixes).