Yes, changing a simple number from one value to another can introduce bugs into an application.
Just look at the fourth Kanai’s Cube slot. While not precisely changing a number, the principle remains the same.
The internal structure of the software likely follows an OOP (Object Oriented Programming) model, which allows for new application objects to create additional functionality all the while inheriting the base properties and functions of the parent object.
Internally, the addition of a 4th Kanai’s Cube slot is probably not a lot of code, because it’s properties and functions are similar to the original 3 slots, with the exception of it allowing for all items types to be slotted. All that is really required is something along the lines of (as an example only):
SLOT_D := CUBESLOT.CREATE;
SLOT_D.ITEM_TYPES := itAll;
SLOT_D.POSITION := 4;
Ok, that is perhaps an over simplification of how it would work, and isn’t a true representation of the internal Diablo III code.
But that one change. That one, seemingly simple and unobtrusive change has introduced a set of bugs in it’s own right. We’de not be getting an extension of PTR 2.6.10 if it didn’t:
That article clearly states that PTR 2.6.10 will be extended with the Shadow Clones theme being turned off and then again later with the 4th Kanai’s Cube being turned off.
This is to provide a mechanism through which they can determine which of the changes (Theme or 4th Slot) is responsible for the latency issues people have been experiencing.
That’s the way software development works. Changing something will always introduce a bug of some kind, even if not in the way you might expect.
Sure, anybody can do the math and draw their own conclusions. Only the Diablo III team can do the math and implement the changes without breaking it completely.