Deprecated - Drupal core

I downloaded and tested 4.6 only to find a vital function I use daily in my 4.5 installation, to be disappeared from 4.6. BlogIt and "Post as Story" links are crucial to the way I run my site and from some searching in the forums here others as well.

I've seen various requests on the forum for a setting to remove the "$user's blog" link based on a setting accessible to the admin. I made one of those requests in the past.
There are various reasons to do that, most of them gravitating around usability.

Here's a patch against 4.6.0 to add an admin setting that, if disabled, will remove the "$user's blog" link from the blog nodes.
Seems to work fine on my blog: http://florin.myip.org/blog/
Please add the patch (or a washed-up version of it) to the Drupal code base.

In reviewing drupal 4.6, I noticed that it seems to load most or all the core code and all the modules for all requests, regardless of whether the code is needed. Perhaps the code could be structured to load includes conditionally? Here's my debug list of includes:

DEBUG:
    1,056 - /src/drupal-4.6.0/index.php
   17,650 - /src/drupal-4.6.0/includes/bootstrap.inc
    4,323 - /src/drupal-4.6.0/sites/default/settings.php
    9,253 - /src/drupal-4.6.0/includes/database.inc
    6,611 - /src/drupal-4.6.0/includes/database.mysql.inc
    2,098 - /src/drupal-4.6.0/includes/session.inc
    6,097 - /src/drupal-4.6.0/includes/module.inc
   60,883 - /src/drupal-4.6.0/includes/common.inc
   26,858 - /src/drupal-4.6.0/includes/theme.inc
   14,433 - /src/drupal-4.6.0/includes/pager.inc
   32,970 - /src/drupal-4.6.0/includes/menu.inc
    6,239 - /src/drupal-4.6.0/includes/tablesort.inc
   16,937 - /src/drupal-4.6.0/includes/file.inc
   30,783 - /src/drupal-4.6.0/includes/xmlrpc.inc
    8,394 - /src/drupal-4.6.0/includes/image.inc
   49,549 - /src/drupal-4.6.0/modules/aggregator.module
   20,653 - /src/drupal-4.6.0/modules/block.module
   10,504 - /src/drupal-4.6.0/modules/blog.module
   32,514 - /src/drupal-4.6.0/modules/book.module
   76,258 - /src/drupal-4.6.0/modules/comment.module
   62,976 - /src/drupal-4.6.0/modules/event/event.module
   10,496 - /src/drupal-4.6.0/modules/event/event.theme

"The comment controls let the user change the default display mode and display order of comments." This option is great, since I was making a poll on my site and 50% preferred "old->new" and 50% "new->old". To please both groups I was thinkning to introduce this control, so that they can select their preference.

However I think it's too much to display this control for each and every post. Is there a relatively easy way to move this useful control under the user accounts rather than under each post?

Recently my folksonomy, or "free tagging", support has been committed to Drupal HEAD. Since the general public won't see this until Drupal 4.7, and there was a fair amount of "hey! I wanna use this now!", I've backported it to Drupal 4.6. In a nutshell, the core difference is the input method: unlike normal taxonomies which are administratively controlled, a "free tagging" vocabulary allows tag creation when the node is submitted. It does this through a text input box, as opposed to a dropdown or selectbox.

Hello. Throughout running Drupal for the last 3 years, I've consistenly run into issues with Timezone handling in one form or another. In some versions, it just plain has been broken and I've hacked the code to correct it and has been extremely inconsistent. In others, it's mostly fixed, but modules misbehave when handling timezone calculations.

In addition, it appears no module or time functions in Drupal make any account for Daylight Savings changes. I have to go change the site wide timezone settings to reflect the changes (eg GMT -7 becomes GMT -8, then back to GMT -7). I'm fairly certain that there must be code out there that calculates the Daylight Savings change dates, and could be applied to the logic.

I'm curious if it would make sense for a full blown new core module to be put in place ... or somewhere in the existing core ... for a full API to Timezone handling. This way any module that wants to touch a time string doesn't have to do it. Then time can be managed and applied in a consistent fashion. If such a function already exists, I would hope that existing modules that muck with TZ settings are corrected? Particularly the event.module.

I'm not certain if this has happened to a degree ... seeing in 4.5.2 and 4.6.0 the "user configurable timzeon" options seems like it's a beginning.

I run a bunch of websites whereby the Event module is an integral component. It definitely seems to be one of the biggest offenders of timezone mucking.