I voted no.
I basically have 2 or 3 ideas a month about things that might make sense for Bitcointalk, but I keep most of them to myself, because after the initial excitement wears off, I ponder them more deeply and almost always come to realize that they are flawed in some subtle (and sometimes not so subtle) way and/or that they would throw off the balance that theymos has (presumably) worked so hard to achieve. It's really hard to find things that would be
strict improvements (that is, ideas that would have nothing or almost nothing but upside if they were implemented). It's easier (though still hard) to find things that might/will create new problems but that you're almost certain will solve an even
bigger problem (or set of problems) in exchange. So, if I were you, I'd start by asking: "What is the problem (or set of problems) that I'm aiming to solve?". If you can't come up with a really clear problem-statement, then, in my experience, it's usually not worth unpacking/debating the details of the solution (at least, not yet). Another way to think about it (just abstractly, I mean; there are no general-purpose units that I know of that would let you reason this out concretely), is that if you can't estimate the magnitude of the problem(s) being solved, then you have nothing to weigh against the magnitude of the problem(s) being caused.
(I mean, I know that sometimes the answer to something can present itself
before you actually know the question, but, in general, that's a really inefficient way to work. A semi-related example that comes to mind is that I think the constant factor of 0.5 in the sMerit calculation could be swapped out for a rank-dependent value: that is, instead of the per-transaction sMerit calculation being something like
sMeritBalance += meritsReceived * 0.5, it could be something like
sMeritBalance += meritsReceived * LUT[receiversRank], or even something like
sMeritBalance += meritsReceived * LUT[receiversRank][sendersRank]. In either the 8-entry 1D LUT case, or the 64-entry 2D LUT case, the values could all be set to 0.5, which would keep things working like they currently do, but, I have a hunch that experimenting with those values could have multiple benefits: it's easy to come up with LUTs that would make it much harder for unestablished accounts to rank
each other up, or LUTs that would make the merit system less source-dependent by generating sMerit a little more generously for the higher ranks, etc. but because I came up with this idea
before I had a specific problem in mind, I've just been sitting on it, struggling to arrive at a really convincing argument for why it should be implemented. But, I also can't just push if off my plate, so to speak, because I think it's likely the solution to
something, I just don't know
what.)