Sorry about that, but just enabling the extension shouldn't cause any line ending changes by default, it's the encode/decode which does that (which is why I removed that from 1.0.4). Having the eol extension enabled just means that if a project does have a .hgeol configuration inside it, your client will obey the rules.
I've never really understood Mercurial's position on treating eol conversion as last resort, since Git (and Subversion / CVS before them) recommended the opposite. If you don't use eol conversion in a multi-platform project, half the people have to remember set their editor line ending settings to the opposite to what's native for their platform. I ran a large multi-platform open source project for 10 years, and trying to rely on people getting their editor settings right usually resulted in complete disaster. Maybe devs on other projects are less fallible. Of course if you're only ever working with one platform then you don't have to use eol conversion and often existing projects don't have it for this reason, which is why the default encode/decode was a step too far and we took it out.
Yes, that's correct. Enabling the eol extension provides the ability to do the conversion, but doesn't do it unless rules are matched which triggers it (the encode/decode settings set this to automatic, ie all text files, but we dropped that). encode/decode actually come from the old win32text extension but work with eol too, if you're using .hgeol there's a new format to use - you set the 'native' line ending format (the one inside the repo), and then set 'patterns' to match which files to convert into the native format (and back again). More details here: http://mercurial.selenic.com/wiki/EolExtension