I'm using python 3.5.4.
The site gives me two headers:
<CIMultiDictProxy(... 'Set-Cookie': 'LOGIN_SESSION=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.etoday.co.kr', 'Set-Cookie': 'LOGIN_SESSION=18676-0.53621000; path=/; domain=.etoday.co.kr' ... )>
I'm using aiohttp that iterates the headers and if it's set-cookie, calls SimpleCookie.load(). The latter maintains a dict inside by the cookie name.

So that's what happens, first we add a dict entry with LOGIN_SESSION=deleted and phony expiration date. Next cookie, the valid one, gets into the same dict entry, updates the value to the right one, but expiration date remains in the past. The result is that this cookie is not used.

I don't know the good way of handling it. Maybe clear the cookie fields before updating the dict? Or this behaviour is intended? I think the situation itself is wrong, the site shouldn't be sending this, but how to cope with it?

This tracker is for modifying the cpython distribution -- the interpreter, stdlib, doc, and other associated files.  Questions about using cpython and 3rd party libraries like aiohttp should be directed elsewhere.

So, the relevant question here is whether http.cookies has a bug.  I reproduced the reported behavior in 3.7.0b1.

>>> from http.cookies import SimpleCookie
>>> sc = SimpleCookie()
>>> sc.load('LOGIN_SESSION=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.etoday.co.kr')
>>> sc
<SimpleCookie: LOGIN_SESSION='deleted'>
>>> sc.keys()
dict_keys(['LOGIN_SESSION'])
>>> sc['LOGIN_SESSION']
<Morsel: LOGIN_SESSION=deleted; Domain=.etoday.co.kr; expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/>
>>> sc.load('LOGIN_SESSION=18676-0.53621000; path=/; domain=.etoday.co.kr')
>>> sc['LOGIN_SESSION']
<Morsel: LOGIN_SESSION=18676-0.53621000; Domain=.etoday.co.kr; expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/>

The Morsel created in the first call is used in the second call because _parse_string ends with

                assert tp == TYPE_KEYVALUE
                rval, cval = value
                self.__set(key, rval, cval)
                M = self[key]

and __set begins with

        M = self.get(key, Morsel())
        M.set(key, real_value, coded_value)
        dict.__setitem__(self, key, M)

Is this a bug?  I know little about cookies, but https://tools.ietf.org/html/rfc2109.html has 
"
4.3.3  Cookie Management

   If a user agent receives a Set-Cookie response header whose NAME is
   the same as a pre-existing cookie, and whose Domain and Path
   attribute values exactly (string) match those of a pre-existing
   cookie, the new cookie supersedes the old. ..."

I don't know if pre-existing means 'previous session', 'previous server response', or 'previous header'.  I have no idea if duplicate cookies in the same response is even legal.  Even if it is, the server would do better to not do so or explicitly give a new expires date.  And if we do 
make a change, we might limit it to future versions.

David, what do you think?  Close as 'not a bug' or 'fix'?

Well, "supersedes" sounds like all the old cookie values should be discarded, so I'd be inclined to call this a bug.  On the other hand, programs could be (inadvertently, probably) depending on this behavior, so I'd also be inclined to only fix it in the next release, since it is a non-trivial behavior change.  I'm open to argument on that, though.

"Questions about using cpython and 3rd party libraries like aiohttp should be directed elsewhere."
Sorry, I thought http is part of "stdlib"? But if sending this here is totally wrong, I beg pardon.

Yes, http.cookies is part of the stdlib.  This is why I continued "the relevant question here is whether http.cookies has a bug", verified the cookie behavior you reported, and added information relevant to its possible bugginess.