My mistake, I’ve edited the comment. It’s imported nested blocks which can’t be moved. Blocks created in Rhino can be moved to different layers.
However, I also now found this (which I believe stems from me creating new blocks with the “Block” command, and then copy pasting/moving them):
I can’t post a file since I’m working on unreleased products at the moment.
Ok, my mistake again, it turns out. I do have a block that I created which I can’t move:
block.3dm (508.4 KB)
It actually behaves differently in this export, because when I try to move it in the above file, it ends up on both layers (a phenomenon that has been mentioned before), but in my original working file, it just refuses to move at all.
Here it works normally as I described. You can hide the block by hiding Hull layer, or by hiding the Detail Parts layer. Moving the block to a new layer (Layer 01) will make it that the part can be hidden by hiding the Detail Parts layer or Layer 01. Does it work differently at your side?
Quick answer: you can’t. There is no mechanism in the Rhino tools for selecting a block definition and moving it to another layer. Only block instances.
Considered answer: move everything other than the block definition to another layer and rename the layers to swap their meanings. Not helpful if you have more than one definition and want to separate them though
Regards
Jeremy
But thank you for the answer. 
When you’ve managed to make a Block Instance (and in my case now, actually only two polysurfaces of a six polysurface instance) appear in more than one layer at once, is there any way to “merge” the visibility behavior back to only appearing in one layer?
I am not sure if I understood, so this might be too simple of an answer for you, but if you double click a block you enter it’s edit mode and you can move all content to any desired layer, and then hit the "OK " button to close the block edit mode.
Does that answer your question?
Well, when I did that, now my block instance in question won’t appear at all unless I have TWO specific layers marked as visible at the same time…
Yep, welcome to the world of blocks… You can put the block instance on the same layer as the block content if you like though.
This behaviour is the same as in AutoCad and is great if you want to put a “chair” in different design proposals sorted on different layers, or different building layers above each other. Then you want to hide different “groupings” of blocks with out hiding their contents.
It hurts learing new “logics” when they don’t appear logic to you, but as great designers say:
“If you don’t like it, get used to it!”
So good luck on battling your head around it and keep on asking questions!
Hi,
I’m struggling to understand what you mean here.
If you create a block definition that includes objects that originate in different layers then the objects have the attributes of those layers (including visibility) but when it comes to their instances they don’t exist in those layers - they exist as sub-elements of the instance. However, if you change the attributes of one of the layers, that change propagates to the parts of every instance that derive from that layer, giving the illusion they are on that layer.
To add to what @holo said about editing, after the double click, when you are in block edit mode, you can select any (sub) part of the block and edit it individually. When you come out of block edit mode, all instances of that block update. (Going back to block definitions: if you want to edit a definition, you have to have an instance of it in order to do so).
However if you mean that you have an entire instance appearing in two layers, then I suspect you have two instances. Select them both and display their details to compare their ids to check.
Incidentally, you can control the colour of (sub) parts by changing their colour allocation in properties. If you set the colour to ‘by parent’, that element takes on the colour of the layer hosting the instance instead of the original block colour scheme.
Jeremy
Thanks, ok, so…
Fantastic! Welcome to the world of Ux design in 2019.
That sounds like a terrible designer. If you don’t like it, re-design it, and by god I hope the McNeel employees do! 
Well, they do exist on a layer, but hidden away. You only see their detail by using an instance as a proxy.
Er, no again. The instances of objects in a block exist within their block instance, which is on whatever layer you put it. Those objects reflect the characteristics of the layers on which the original objects were drawn, but they are not on those layers (try selecting objects by layer to see this).
You got that one!
Yep. That’s because block definition “components” (for lack of a better way to describe then) are not real Rhino objects - they are not stored in the object table and they do not have an object ID (that’s why you can’t select them).
Block definition components are simply a collection of information that describes the geometry of the original objects plus their “attributes” - “attributes” being things like layer, color, linetype etc. The block definitions themselves reside in the Instance definition table (not in the object table).
When you add an instance of that block definition to the file (by using Insert or whatever) the instance does get an object ID, so you can select and manipulate it like other Rhino objects. And, like all other Rhino objects, a block instance necessarily resides on a layer.
All that being said, the way blocks work in Rhino is basically inherited from AutoCAD. Blocks in AutoCAD existed long before Rhino did; the way they work is more or less AutoCAD-compatible. As @corey.hokanson very nicely explained above, if set up correctly, they can be very useful.
Despite people’s long explanations, I still maintain that it’s utterly unusable when it comes to an industrial design assembly, though.
I really hope that perhaps Rhino V8 implements a parallel system that you can choose upon import, that looks more like this.
As long as blocks are in place and works the way they do, Rhino will remain a curiosity at our company (well, due to that and filleting, I guess).
@eobet you’re exactly correct. Rhino’s block and layer system is not an assembly manager like you’d find in SolidWorks. Blocks were never designed to be an assembly management system, nor were layers. Rhino adopted an AutoCAD-like way of data organization with blocks and layers, and then added a CATIA-like Worksession manager - which also isn’t an assembly manager.
I think you’ve discovered that if you approach our tools as if they were something they are not, they will disappoint you. I can’t tell if you’ve read the documentation about what blocks are and how they work - in case you haven’t, here’s the help topic.
I’m really not sure if you can make Rhino work the way you want it to. It also looks like we did a disservice by importing a complex model into a bunch of nested blocks for you. Where did this file come from? I presume it was a STEP file? Blocks, as you’ve found, are the closest things to assemblies that we have - though they’re woefully inadequate. Would it have been better for us to import each part onto its own layer, but not have them in blocks?
Providing an option for that is never wrong. Options are never wrong. 
(Except for when they aren’t)
// Rolf
Yes, it was a STEP file, and in my case, that would mean several hundred layers, which, if they’re not nested, would also be completely unusable. It also would mean that I can never export the file again, because all structure is destroyed.
Sorry, but the proper solution is still this.
Rhino is just plain the wrong tool for you then, I’m sorry. There are lots of CAD programs that do feature trees exceptionally well. I encourage you to use them.
What led you to believe you needed Rhino?
Sorry Brian, but this is complete nonsense. Just because @eobet complains about one feature doesn’t mean he can’t use or doesn’t need Rhino.
There are many threads by now that indicate that blocks are very cumbersome.
I can’t see why Rhino doesn’t need an assembly manager just because there are solid modelers that have this. I would very much welcome a proper assembly manager so that we can work with files coming from clients more easily
