I think a better approach is the one taken with #menu, where the initial declaration is in index.php, and when underlying elements are passed in by the called functions, they come in without any hard-coded style settings themselves, but instead take their style info via cascade, from settings in the stylesheet such as '#menu ul', '#menu ul li', etc.
You say, "When upgrading if someone wishes to continue using an older style sheet and index page..."
With respect, that's not an "if". People with established sites will not only wish to continue using their existing index and stylesheet files, they will expect to do so, and many will expect to do so without knowing a blessed thing about how the PHP part works, just which calls to type in to get their sidebars and content sections and so on out of the database and onto the screen. So I think retaining the statement as
echo <table id="wp-calendar">; may serve to build in an unnecessary support issue, since many do expect style assignments to be made out in the open, and will design their templates as though that were the case.
You rightly point out that my changing the functions file means that future upgrades will break my index; but as it stands, the current upgrade broke (okay, bent) my index, so I'm kind of seeing this as a six of one dilemma.
This all sounds as though I'm saying, 'you people did this wrong!' and that's not what I mean at all. It's just me saying how things looked from where I sat last night, not being particularly familiar with WP, or indeed dynamically generated html. If that's useful to anyone, great, if not... :)
And when it comes down to it, it took me no more than five minutes to see where the CSS conflict originated, and since you've kindly confirmed that the echo statement in the functions file is a deliberate choice, I'll factor that in when I get around to adjusting my temporary quick-fix solution into a more permanent one.