All the talk ive heard is to put identical data in multiple nodeletss. My preference is to remove said data from both nodelets and put it in its own place. I dont think a slim nodelet with this data is a bad idea. Especially if it reduces the complexity of other nodes. Consider that corion posted the base link text patch only to one of the nodelets, wheras it would be useful for both. But there isnt much call for non developers/gods from having both enabled at the same time. Thus we have at minimum a serious target for refactoring.

As for type, i believe this could be easily triggered by such things as membership in SDC or PMDev (both which have good reason to know the type of a node). But to be honest i dont think its a bad thing to expose the common user to this information. After all we are a learning site, and learning about PM represents some form of education. Even if in the worse case its a lesson in how not to do things. (Something I obviously dont believe, but im taking the worst case perspective here.)

Just to follow up while im suffering insomnia, if you look at the code for Super Search the text block at the top (in the q()) has 4 columns. the 2nd through 4th columns represnt nodetype, section abbreviation, and section name. (The section name is optional and is only needed if the abbreviation!=section name). We should turn this info into a Setting and expand it to cover all nodetypes. (Its a pity nodetypes don't have a way to store this...) Then this can be used for whatever it is we end up doing.

As for id and type, i want the Id for the same reasons Bart outlines. I want the type because for a pmdever such information is very useful. I want the id and author in a raw form because for various things such information is useful in a n "un-urled" form. Eg, making a nodepin you need the id, currently its a bit of a pain to do.

And yes ultimately i think much of the redundant info would be better off in a single nodelet. Even if folks want it the other way I still want that nodelet. So I think the best thing is to make a htmlcode node that is used to provide this info. It should adjust itself appropriately based on parameters so it can be tailored for reuse in other nodelets if thats what people want, but it should also handle various logic like group memembership and $VARS determining what people see. Essentially the nodelet i want would have all the special links at the top of the pmdev nodelet, and the stuff at the top of each node, along with assorted related bits from the other nodelets. Presumaby this nodelet would just a be a special case of the htmlcode node i have in mind.

Pesky time keeps disappearing though so I havent got a prototype put together though.