Summary. Yes, this is possible. It's not a browser bug. It is part of the as-designed functionality of cookies. There is no browser that is safe from this. Cookies are ancient technology and their security model is only loosely-integrated with the rest of the web. The details are messy and ugly.
The gory details
The site blog.example.com can set cookies with scope blog.example.com or with scope example.com. Cookies with the latter scope will be sent back to secure.example.com, if the user visits secure.example.com.
If the site secure.example.com sets a cookie with scope example.com, then the site blog.example.com can overwrite that cookie arbitrarily. Whenever browsers see a cookie with the same name and scope as one that's already in the cookie jar, they discard the old cookie value and overwrite it with the new cookie. Thus, blog.example.com can overwrite any cookie whose scope is example.com.
Worse still, one cookie can shadow a cookie with another scope. Suppose secure.example.com sets a cookie with scope secure.example.com and name SESSIONID. Next suppose blog.example.com sets a cookie with scope example.com and the same name. Finally, suppose the user visits the site secure.example.com. What happens? It is ugly: the browser sends both cookies, in some undefined order, and the server has no reliable way to tell which cookie value came from which site. So, the server can detect that it is in a confusing situation, but has no good way to unconfuse itself. Worse, some web application frameworks may conceal the confusion from application code, using one of the cookie values and silently ignoring the other. This can lead to something that behaves effectively like blog.example.com overwrote the cookie from secure.example.com, in a situation where no one would reasonably expect that it might be able to.
(As a side note, the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection.)
Finally, there is one other way to delete cookies: a malicious site can set lots of cookies, overflowing the fixed limit on the number of cookies that the browser will store. The result is that the browser "forgets" older cookies from other sites. This allows blog.example.com to delete all of the cookies set by secure.example.com (regardless of their scope), and then set a new cookie with scope example.com that will be sent back to secure.example.com -- which has much the same effect as overwriting an existing cookie. This may be what you were thinking of when you mentioned "cookie jar overflow".
Discussion
It's messy. Sad to say, this is just how cookies work on the Internet. If you want to avoid it, the simplest defense is to use a new second-level domain for untrusted sites. There's probably a better defense that doesn't restrict the naming of your sites, but I don't know what it is.
As a general note, for questions like these about how the web works, I highly recommend the browser security handbook. It is packed with nuggets. In this case, you might want to read its material on the same-origin policy for cookies.
