Putting this on normal (so it doesnt appear untriaged...) because there is an issue [but only with old dependency graph...]

not an issue if you use the new dependency graph
(run blender from the commandline with the --enable-new-depsgraph option)

About the situation with subsurf and no 'use modfiier stack', not it is clearer to me. The reconnect in this case seems to work like this:

@Philipp Oeser (lichtwerk) Yes, of course. Sorry in case I failed to follow the preferred procedures. No secret that I'm rather new around here.

Hi @Brecht Van Lommel (brecht), @omgold (omgold), I've seen you discuss this on the mailinglist (and I understand reaching out here as for some reason this report seemed to slip under the radar)
But: why not continue here? This way others (including me) can follow and participate much better.
Sorry for the wall of text, but pasting from the mailinglist, so it doesnt get lost...

sorry for the duplicate and thanks for the answer :)

Unfortunately operations that alter topology are not supporting Custom Split Normals:

The problem here is that the "Use Modifier Stack" setting is not properly taken into account for these disconnect/reconnect operations.

In T55210#505645, @LazyDodo (LazyDodo) wrote:

Thank you for the report. Currently we are aware of many issues in 2.8 and actively working to fix them. But since replying to reports takes time, we have decided to limit bug reports to module team members.

Thank you for the report. Currently we are aware of many issues in 2.8 and actively working to fix them. But since replying to reports takes time, we have decided to limit bug reports to module team members.

commited rB69f2305415a2

@Philipp Oeser (lichtwerk) : your work here is really aprecciated - thanks again for taking the time to fix this issue so soon!

@Lukas Ziechmann (bl_cat): note this isnt commited to master yet (want to check on an issue in 2.8 first so the merge would go smooth ...)
reg. T54397: surface deform is now ported as well, but changes can happen later as well [just need proper handling of 2.79 vs. 2.8], lets stick to that report and continue discussion there

*wow* - getting back from work to find the bug I reported yesterday to be already fixed for 2.79. Thank you so much @Philipp Oeser (lichtwerk)! Regarding my other bug report: T54397 , do you think I should CC a 2.8-developers directly as the surface-deform modifier isn't ported over to 2.8 yet or would that be considered annoying/ unhelpful? I don't know the policy here and I don't want to clutter their chat with unimportant messages. Thanks again for your time and effort!

LGTM

missing NULL check

lattice was already ported (see T54737), so this will need to go into 2.8 with minor tweaks separately

this probably wont merge into 2.8 cleanly [DerivedMesh → Mesh conversion], I guess I'll have to make another version for 2.8 as well [which should only be minimal massage].
CCing @Sybren A. Stüvel (sybren) , just so he knows...

D3239 should fix this

similar to rB9c95fd0a988fcd14f050098385e5461e2e51100d

Will have a look shortly

commited rB288d7794d4c6

possible fix: D3199

Just thought this could go in before this modifier gets ported in 2.8?

I'll leave porting the Particle Instance modifier to @Philipp Oeser (lichtwerk) then ;-)

@Sergey Sharybin (sergey): got it working, will post patch tomorrow (just saying, so @Sybren A. Stüvel (sybren) is not porting this modifier over in 2.8 before we merge?)

We are talking about the very first bone here, right (the one marked as 'root')?
Confirming on first sight.

Depsgraph indeed only takes layers into account. This way it's cheap to see if some object from hidden layer affects something currently visible. In Blender 2.8 we are switching to collections visibility instead of object visibility. This part is still being worked on, so need some work to make depsgraph aware of that once rest of design is locked down.

At a quick glance at the code, dependency graph is only aware of layers, not object visibilities at all.
This is not limited to the Armature modifier, seems all modifiers evaluated (e.g. on frame change)
(Above difference in fps between visible vs. hidden is probably drawing code etc, not modifier evaluation).
So in that case, I would think this is a (somewhat known) limitation to the depsgraph?

While it is very well possible that hidden objects need to be evaluated (think of something shrinkwrapped to a hidden deformed object - you would want the deformations to be evaluated), it doesnt have to be so (agree, it would make sense to skip evaluation in that case).

@Philipp Oeser (lichtwerk), this is something what we should support indeed. Mind looking into this? Shouldn't be hard to add support :)

This is a limitation to the current Particle Instance modifier (not a bug though).