1. The current version of the library contains a profound design flaw - it allocates memory. This is not viable in any way. The next release (which is very close to completion, but has been deferred for the last month due to a crisis project at work) does not. Regarding ConcurrencyKit, it is an excellent project, and I know Samy (I was involved in him getting his last job); he is an excellent programmer. He said to me about four years ago I needed to make a new release :-)
2. Regarding ABA and memory reclaimation. There is a comment noting that it is hard to find this information in the docs. I apologise. It is indeed not particularly explained. The docs were written with a view to a non-lock-free informed user wishing to use the API, so technical information regarding the internal implementation is lacking. In the current release ABA is resolved by the use of DCAS (limiting the library to ARM and Intel), and there is no memory reclaimation. In the next release, memory reclaimation has been implemented (removing the limit of ARM and Intel). I also implemented on ARM LL/SC versions of the algorithms, but these have been removed, because it's too hard to know which platforms they will or will not work on. ARM is still supported of course, but by using LL/SC to emulate CAS.
3. The blog, ah, yes. It's where I let off steam in the heat of frustration, which is off course not always pleasent - however, it's nice to vent. I am thinking of getting rid of it though, because it's not very professional.
4. The reason for a new github repo on each release, and the naming strategy, is to permit the concurrent use of multiple releases of the library. By allowing a new release to be used in parallel with old releases, existing code does not have to be modified. This minimizes work and risk. For minor releases and bug releases, where APIs do not change, a global search and replace will permit a full change to the new version.
5. Regarding frames. The site uses a number of third-party applications, such as a forum and a blog. These all emit HTML which assumes they are generating the whole page - they have a <HTML> tag in their output. Their output then has to exist in a frame. If I capture it and send it to a DIV, the DIV renders incorrectly.
Finally, please note the forum (which is fairly new) needs to be upgraded to reduce spam attacks (I've been too busy to do so). Currently I see hundreds of attempts each day, by robots, to generate accounts and so it is impractical to continually scan the lists of requests to find any real requests. The forum does now offer a captch for this, and as soon as I get time (one or two weeks) I will upgrade to this.