@wilsonge would it not be better to use the new plugin system as we are against 4.0? btw. Did you expect to add a joomla brache on upstream?

Since this is a B/C anyway, I'd suggest constructing context other way around: content type.extension
Just like composer packages have vendor/library name

That assumes components only have one content type which isn't necessarily the case. For example in the front end com_content has 3 - com_content.categories, com_content.category and com_content.article (and maybe one more for the form - i don't know off the top of my head). If we are doing that (which I don't really agree with btw) then it should be in a separate PR over all components - not as part of this!

Current proposal (mod_articles_news.content) puts more stress on the extension then on the item type.

At this moment when I'm writing a content plugin such as plg_content_joomlarrssb I'm deciding if to process the item by checking it's type from first string before the dot.

I think that the context should not differ per extension but if it really has to, I'd send it as new parameter to keep B/C or as in comment #8610 (comment) by @ggppdk to use com_content.article@mod_articles_news.

Anyway this may be a serious B/C change and probably all 3p content plugins won't work anymore.

ps:
I agree that in case of content we should differentiate between categories and articles, but I don't think we should make difference between articles, featured and archived at the context level.
You can access item properties and check for these attributes anyway.

Ultimately this is because we really ought to trigger a lot of these plugin events in the model rather than the view. Of course so many plugins give back html that this is pretty much impossible these days....

Closing this for now to move it back into one of my branches so i can finish work on it

@brianteeman @zero-24 please remove the milestone here since this is closed