Interfaces or Attributes for Tagging Classes?

Well, with attributes, you can always create the attribute in such a way that its function doesn't propagate to descendant types automatically.

With interfaces, that's not possible.

I would go with attributes.

You probably have answered on you question by your own. Attributes is more logical here, reflection is not a BIG MONSTER WITH RED EYES =)

btw, can you show calling code, where you determine marked with interface types? Aren't you using reflection there?

I'll have to say otherwise. I think that, for your example, a marker interface makes more sense.

That's because it seems very likely that you might one day add some members to IFood.

Your design starts like this:

interface IFood {}

But then you decide to add something there:

interface IFood {
  int Calories { get; }
}

There are also other ways to extend interfaces:

static class FoodExtensions {
  public static void Lighten(this IFood self) { 
    self.Calories /= 2;
  } 
}

It's an old question, but maybe someone stumbles on it like I did. Seems in this case:

"If the object is Food, I would return FoodEventArguments. If the object were, say, Beverage, I'd return DrinkEventArguments. Basically, there's a common base class (let's say ConcessionStandItem) that gets passed into the function"

tagging with either interface or attribute and then checking with an if statement is not the only option you have.

Might be a valid scenario for the visitor pattern with implementations for each 'ConcessionStandItem' like FoodEventArguments CreateEventArgs(Pizza pizza).... as well.

Maybe food for thought for someone else in this scenario. (pun intended).