Which Blender release did you use? I just tried 0a8af46 from builder.blender.org (blender-2.79-0a8af46-win64) and am still able to reproduce this bug. I updated the "steps to reproduce" and added an "Additional details" section to the description with some more info.

Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckily, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

Thanx for spotting this.
Made a differential in D3487

havent hunted down the related commit, but this seems to be resolved in master?

Very important code style feedback ;)

Update for latest master

Correction, the API was only committed at a very basic level, so keep this open.

Recently released Toonkit also relies on this function. Remove it without any replacement just make impossible to start porting it for blender 2.8.
Any news about it?

Committed to master, closing.

Am not totally happy with it, but looks like operators creating new datablocks usually ensure they have one user, even if not actually used… Image opening one e.g., which can probably generate some usercount inconsistency in some cases. So guess we can do that unconditionally for text opening op too.

I think this has to do with commit rBa9163f7d222d, rB646aa40cf707 (which only ensured real user for doing it from the UI?).
Also see rB15eb83c8b375.
Doing this from python [via bpy.ops.text.open] would skip this step because SpaceText as well as PropertyPointerRNA are not set in this case.
Doing this from python [via bpy.data.texts.load] would also skip this.

Closing revision: issues with performance of selection history can be addressed separately from this patch.

Fixed bad indexing of select_history in modified select_prev, updated benchmark results with code changes

Am not too keen on this, mainly because the selection history is typically not a very large list.

In T47811#476198, @Jeducious (jameshcrowther) wrote:

So, I just downloaded '2.80 (sub 3)', commit date - b'2017-12-22'. I started work on supporting it in our addon. But there is a key handler that we use that has been removed. bpy.app.handlers.scene_update_post is gone??!?!?!

I have checked the discussion above and I think that most posting here were in favour of keeping it, but also not in its current form, and re-purposing it to actually do what its meant to do, i.e. only trigger when there is a meaningful change to the scene that affects the final output of a render, either to viewport or final.

I understand that the problem with the scene_update_pre/post handlers constantly triggering is a big issue. In fact this was a big problem for us at first in using it, but we managed to use it regardless. Not having it though, breaks our ability to efficiently tell if something in the scene has changed and what that something is. With no alternative we'll have to poll and that pretty much means using a modal operator with a timer and we're back to constantly running code again, something I believe we're all trying to avoid in 2.8.

Worse, since we'll be forced to do a search on all data to see what has changed since the last run of our operator, the time taken to process will scale linearly with the number of ID blocks in the scene, so more advanced or complicated blend files will get worse performance with the addon enabled.

Video of the error: https://www.dropbox.com/s/zvw4c1v78n55wef/Blender_Tree_Link_Bug.mp4?dl=0

I tried this on win 7 gtx 550ti master hash d5c1c0b, every things seems okay, I run the script till my Mem was 50.90M i don't remember how many times but more than needed :)

OK, seems like a Windows issue then (I'm on linux as well).
Someone here on Windows can reproduce?

“Does this happen on other computers as well?”

Seems I cant reproduce.
Made several runs in both master and 2.79 (each running the script 100 times)

Confirmed, fix incoming.