Fredrik pressed for details, but we haven't seen any concrete use cases. In the absence of the latter, it's impossible to guess what would be backward compatible for MAL's purposes.
For my purposes, the strategy buffer slice returns a buffer would be more appropriate because it would save the buffer type information across the slicing operation... I mean, you don't want to get bananas when you slice an apple in real life either ;-)
I use buffers to mean: this is a chunk of binary data. The purpose is to recognize this type of data for pickling via xml-rpc, soap and other rpc mechanisms etc.
How do you use buffers? Do you stick to their C API? Do you use the Python-level buffer() function? If the latter, what do you do in Python code with a buffer object after you get one? The only use I've seen made of a buffer object in Python code is as a way to trick the interpreter into crashing (via recycling the memory the buffer object points to).
And from where do you get a buffer? There are darned few types in Python that buffer() accepts as an argument. Do your extension types implement tp_as_buffer? I'm blindly casting for a reason why your appreciation of the buffer object seems unique.
Strings don't provide this information (since they can be a mix of text and binary data). Buffers are compatible enough with most tools working on strings that they represent a good alternative to tag data as being binary while not losing all the nice advantages of strings. The downside is that most of these tools return their results as strings :-(
Now it would be nice if at least the type itself would behave in a sane way.
Overall, this reinforces the repeated observation that we don't know why the buffer object exists -- it doesn't appear to do what you really want, but you've found some way to get it to do part of what you want, up until the point you actually use it <0.7 wink>.