Please always attach sample file which demonstartes the issue.

For now i would say you're looking at render result in RGB display. Internally all display buffers are byte buffers with straight alpha, when you'll look at them in RGB mode result would be aliased indeed. RGBA display shall be fine.

Thanks for the report, but this is not a bug, just changes in how alpha is treating now (and it was treating wrong in older versions).

P.S. If it's not your case please provide sample file which would clearly demonstrate your particular issue.

I know the display mode in newer version has been changed, but In older version (ie r53946), even in RGB display mode the edge is perfect (please refer to the attached files). The new version looks jaggy in RGB mode and just seems quite unneat....

It looked OK-ish because in older versions premultiplied image was displaying on a display configured for straight alpha. This made image looking anti-alliased in this case, but it also was a reason of blurry edges (like caused by motion blur) looking darkish.

Agree it's a bit confusing, but current behavior is correct from math point of view, we just lived far too long with incorrect alpha...

This doesn't affect the actual production use, just visually feel a little imperfection... From an animator's point of view I personally prefer the older version, which displays perfect images no matter which mode they are. Anyway thank you for the prompt reply!

This is just typical for premultiplied alpha, because the color in full transparent regions is entirely undefined, and therefor you have no color anti-aliasing at borders from fully opaque to fully transparent.

Additionally you loose color quality in highly, but no entirely transparent regions. I never understood why this should be beneficial in comparison to straight alpha, and so far no one could tell me good reason why we now use it, despite the typical comment that "others do, for some unknown reason". In my experience any graphics program that uses straight alpha has no problems with alpha information (for example gimp), but any other program that uses premultiplied alpha (for example inkscape) does.

This has nothing to do with the render being premultiplied alpha, look at the RGB channels without alpha in the Gimp, they look the same. In fact the reason you see them now is that RGB colors are displayed as if they used straight alpha. I'm not sure what color anti-aliasing is, but if that means mixing in colors from the background it's going to lead to color fringes when compositing images.

Further there is no color quality lost because premultiplied images are stored in float precision, we're not using 8 bit precision here.

The reason we use premultiplied alpha for renders and compositing is that it is the natural way to store images that represent light being emitted to the viewer, storing them as straight alpha means you are throwing away some information. For e.g. diffuse image textures straight alpha is ok, and byte images are stored as straight alpha in Blender. And it's true that float precision image textures could perhaps be stored as straight alpha too but it's a simplification we made to get this implemented efficiently and clearly.

If you want a reference for why premultiplied alpha is a good idea for rendering/compositing, don't use Inkscape as a reference, but think of Nuke, PRMan, OpenEXR, Pixar, ILM, SPI .. where this has been a standard for a long time.
https://groups.google.com/forum/#!topic/ocio-dev/ZehKhUFqhjc/discussion

If you divide by alpha you will of course loose color quality, even with floating point. The simplest example is using an alpha which is equal to 0. It makes perfect sense to have R/A if A is zero... huh... seams mathematically well defined... But even for very low alpha values this is problematic.

In the special case of "light" it makes some sense and feels natural, but there is much more then just light. In case of compositing (which is not only about light) it does not make much sense. The same is true for texture painting and other stuff. At the end we are stuck with dozens of conversions, slowdowns and fringing issues.