The behavior that was noted does not align with the ECMA specification's requirements found at this link.

According to clause 8.5 in the specification, the Number type should adhere to the IEEE-754 64-bit binary values, except there is only one NaN. As a result, it is impossible to represent 2.175 exactly; the closest possible representation is 2.17499999999999982236431605997495353221893310546875.

As outlined in section 15.7.4.5, when using toFixed(20), an algorithm is utilized that can be summarized as follows:

• “Find an integer n where the value of n ÷ 10^f – x is as close to zero as feasible. If multiple options exist, choose the larger of the two ns.”
• In this scenario, f is set to 20 (representing the number of digits required), and x represents the operand, which in this case would be 2.17499999999999982236431605997495353221893310546875.
• This calculation results in opting for 217499999999999982236 as the value for n.
• Finally, n undergoes formatting, leading to the output “2.17499999999999982236”.

Eric's input is appreciated, but respectfully, it doesn't directly address the question at hand. Admittedly, I may have used some playful language with terms like 'right' and 'amazingly correct,' but I do recognize that Internet Explorer's behavior is indeed unusual.

Nonetheless, my quest for understanding the root cause of IE's unique behavior led me to an intriguing clue - ironically found in Mozilla's bug tracker through this extensive discussion. Here's a snippet from the conversation:

OUTPUT IN MOZILLA: 
a = 0.827 ==> a.toFixed(17) = 0.82699999999999996 
b = 1.827 ==> b.toFixed(17) = 1.82699999999999996

OUTPUT IN IE6: 
a = 0.827 ==> a.toFixed(17) = 0.82700000000000000 
b = 1.827 ==> b.toFixed(17) = 1.82700000000000000

The divergence between IE and Mozilla lies in how they handle values. In IE, 'a' is stored as a string, whereas Mozilla stores it as a numerical value. The specifications don't specify the exact storage format. Consequently, when IE executes a.toFixed, it retains the precise string representation, while Mozilla undergoes additional conversions leading to inconsistencies.

A formal confirmation on this matter would be ideal, but for now, this explanation sheds light on all observed phenomena. This becomes particularly evident in scenarios like:

console.log( 0.3.toFixed(20) ); // 0.30000000000000000000
console.log( 0.2.toFixed(20) ); // 0.20000000000000000000
console.log( (0.3 - 0.2).toFixed(20) ); // "0.09999999999999998000"

First and foremost, it is important to note that Floating points cannot be precisely represented in binary numbers. There will always be a slight elevation or depression in the value, leading to either a slightly higher or slightly lower representation. The extent of this elevation or depression depends on the method of conversion used, making it difficult to pinpoint an exact "correct value" even with ECMAScript's toFixed() output.

The ECMA Standards aim to establish consistency by setting guidelines for implementations. This helps standardize practices and minimize discrepancies across platforms, ensuring that errors are consistent rather than varied.

Therefore, the question arises: why does Internet Explorer deviate from these established standards? To explore this further, let's analyze a series of test cases comparing IE 10.0.9200.16688 and Chrome 30.0.1599.69 on x64 Windows 8 Pro.

Case Code                       IE (10)                        Chrome (30)
--------------------------------------------------------------------------------
A    (0.06).toFixed(20)         0.06000000000000000000    0.05999999999999999778
B    (0.05+0.01).toFixed(20)    0.06000000000000000500    0.06000000000000000472

Interestingly, whether in IE or Chrome, we observe that (0.06) is not equivalent to (0.05+0.01). This discrepancy can be attributed to the inherent representations and very minor errors associated with floating-point calculations. These small errors accumulate during operations, resulting in a slightly different total magnitude error.

The variance in represented values between browsers can be influenced by two main factors:

• The specific conversion algorithms employed.
• The timing of when the conversion occurs.

While the exact algorithm used by IE remains undisclosed, the above test cases clearly indicate that IE and Chrome not only handle conversions differently but also execute them at distinct instances.

In JavaScript, when a number (an instance of the Number class, with or without the new keyword) is created, a literal is provided. This literal, although representing a numerical value, is internally treated as a string by the browser. The browser parses the literal, creates the object, and assigns the respective represented value.

Here's where the differentiation arises – IE delays the conversion until necessary, maintaining the number in its original literal or intermediary form until an operation triggers the need for transformation. On the contrary, Chrome promptly converts the number into its operational format upon creation.

Following the completion of an operation, IE retains the calculated value without reverting back to the initial literal or intermediary form to prevent any potential loss in precision.

This explanation aims to shed light on the nuances of how browsers approach and handle floating-point calculations.

^[1] Values represented in code are always literals; if enclosed in quotes, they become String Literals.