Which, it should be noted, has actually always been a bit of a problem with Ruby's GC. Particularly when it comes to C extensions that can't or won't use certain patterns to hint to the VM about how much memory they're really using.
I remember a really common memory issue with ImageMagick's extension along these lines back in the 1.8.x days. ImageMagick allocates huge objects and gave the Ruby VM very little insight into that fact because it used its own malloc. You'd wind up with a perfectly normal, in terms of memory use, Ruby app that didn't trigger GCs often enough and the IM objects wouldn't get cleaned up in a timely way, so it looked like you had a huge leak. You'd then spend days trying to figure it out.
Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking.
Official Contributing Guide: http://ruby-doc.org/core-2.1.1/doc/contributing_rdoc.html
Ruby Hacking Guide: http://ruby-hacking-guide.github.io/
Book on ruby internals: http://www.amazon.com/Ruby-Under-Microscope-Illustrated-Internals/dp/1593275277
RubySpecs: http://rubyspec.org/
But, to be fair, it's a bit of a goose and gander kind of situation. People everywhere else in the world have to deal with that kind of situation all the time.
In addition, it's only that mailing list that's split; the bugtracker is in English, the help is all in English (with one or two 日本語 translations).
It's actually never been easier to contribute to Ruby.
It might also be possible to create a sort of "weak reference" String-type class where you can manually ditch the data associated with it and not wreck other references to it, they'd just revert to empty string.
Seems like this could be done without having to get down and dirty in the GC itself.
The article claims this got worse with the new generational GC algorithm, which sought to minimize the amount of work the GC has to do during the collection pause. By marking long lived objects as probably OK, you end up with fewer objects to free per GC cycle.
The problem then, is if you allocate some massive strings, and they get marked as "old" then they might never get collected by the GC. It's not clear to me if the article author sees it this way, but apparently there is some kind of bugs where some class of objects get marked "old" by accident, and it sounds like it's exacerbated by existing interpreter architecture.
Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking.
Anyhow, so, my understanding of your question is no, it would not help outside of really specific optimizations? It depends on what this Buffer class would do. Would they let you mark them as being young? Or avoid extra malloc calls because you have special information on the size of your strings? Kinda depends on how the generational algorithm was implemented? At this stage my knowledge grows thin.