Someone randomly asked for a comment on irc, so since I actually
do have an opinion, here it is.

I think this would be a rather backwards approach to dealing
with this issue since treeview would have to become more and
more complex to accomadate weird situations.

Instead I wonder why not implement a proper dissociation between
the actual treeview content area and the column headers, 
provide them as a separate widget (or just an api to get the
translated column names and such ?), maybe provide a 
convenience composite widget that displays column headers to cover
typical use cases, let people put column headers and separators
wherever they want.

(In reply to comment #1)

What I'm interested in general in is having widgets (a bit) more themable so that changing the *looks* requires zero code changes. In my opinion switching from GNOME HIG layouts to Maemo layout - and vice versa - should require no code changes as far as spacings are concerned. Spacings should be more or less completely defined by a style sheet if you please.

What you're proposing sounds an awful lot like encouraging that theming is to be done in conjuction between gtkrc and code - that you simply can not alter the layout without also going to the code. One of my pet peeves current is that gtk seems fairly confused in this area currently and I'd rather not add to the mess.

What comes to radically distancing the column headers and separators from the content, I just don't see the point.

What I am interested in here is to have the most powerfull set 
of small tools as possible.

If the column headers were separate from the treeview content widget,
then a composite widget could still be made to do all these things
natively and IMO the right kind of complexity stays in the right kind
of widget - it could even go ahead and implicitly add a separator
based on some setting and that code wouldnt interfere with the treeview
code. furthermore this leaves room for better flexability where any
applications want to do something a little bit custom.

I do understand there is a fine line here, some tradeoffs to make
gtk+ easily usable also sometimes make it more rigid, I just think 
that if such guesswork about layouts should be done by gtk+ at all, 
that stuff should be done by some composite widgets so as to provide 
a proper abstraction between the pure UI elements themselves and 
the typical widget layouts that users end up seeing on screen.

I am not choosing sides here at the moment, but a custom header implementation (probably GtkTreeViewHeader) would probably also allow for fixing the problem with embedding other widgets than a button in the header.  (I have no idea how easy this would be to implement since the current column headers and tree view are pretty much tied to eachother ... would need investigating).

Kristian, that would rock. I currently stick with hiding the header and use a table.

This bug has been quiet for a while, but it still looks like a useful feature addition. The ability to implement a custom header sounds interesting, provided it can still be themed.

nothing happened here, but treeview header styling is certainly more flexible nowadays, with css