Okay, but that is not what is going on in my example. There is only one builder method; the second method is called via the modifier "after" which guarantees do_n() already happened. Ie, do_n2() is only called "after" do_n(). The problem does not matter much since there are other ways to accomplish the goal (eg, assigning do_n2() as a lazy builder method work

Okay, I see what you are saying and I see what the issue is now.

So what is happening is that the builder method do_n is being called, and the return value of that method is then taken an assign to the 'n' slot. Your method modifier is called after the builder method, meaning, it happens before the actual slot assignment, hence 'n' always being null.

I usually don't recommend using method modifiers with things like builders since it can get very hairy and really, that is what lazy & default/builder are for (as you discovered with your lazy_builder solution).

It just makes me suspicious of the use value of the Moose style method modifiers

Well, there are plenty more uses then just this :)

If I assign an "after" method but changes made to the object in the triggering function have not take place when its "after" method is called, does that not make using such a method modifier very problematic????

Yes it would, but as I pointed out above, the modifier didn't fire after, it fired before. The builder method is not the right place to wrap this stuff. Moose does not perform any magic in this sense, if you have assigned the slot (or called the accessor to assign it for you), then the change will be there. I think this was just a simple misunderstanding of when builder is fired in the chain.

I guess it could be used, but let's say the action taken was that a string value was changed, and I call an after modifier method to record the change -- BUT the value is still the same as it was prior to to the action that "was" taken, then how can this modifier method log the change correctly?? It will record the previous value, not the new one, since the object it receives does not reflect assignments made in the method it "modifies after".

It is outside of the responsibility of Moose to decide if your value actually changed or not, Moose only knows (and only cares) that you called a method, PERIOD. If you want this kind of thing you will need to write it yourself on top of Moose, as a MooseX:: module perhaps, but it most certainly does not belong in Core Moose, if for nothing more then the notions of equality are not universally agreed upon.