IMO the closest thing to hitting all of these of which I am aware is Luna. But it fails on two big counts: (1) it is not closed— IIRC they wrapped Haskell. In particular, Haskell expressions were exposed in the editor, requiring the user to be able to speak Haskell in order to be able to use Luna. This is not a small mistake— the set of users who would need to use a visual tool the most are excluded from using it right off the bat. (2) The UX was, for a node-and-wire tool, not very good. It was visually "snazzy", but not very usable (no offense Luna devs). It seemed to me like the designers either weren't familiar with mature node and wire tools, or failed to learn from them. If there is something that hits all of those, I would be very interested in knowing about it! Also curious what y'all think about each of those points and/or if something is missing.

I doubt you can design make a closed system that is practically useful for enough people. You need to interface with the outside world, because that's where (1) all the interesting existing stuff lives and (2) everyone else is having fun. Closed design has always been a problem for Smalltalk, and led to modern Smalltalks being more open (e.g. Pharo having a foreign-function interface, code management in Git repositories, etc.).

Sure— Openness to other systems isn't a bad thing; it's when you have to leave the system to express certain basic transformations. I'm not really referring to using FFI to access external libraries, more being unable to perform basic programming concepts. For example: It's common in node-and-wire tools that they don't offer any method of iteration. So if you want to repeat an operation, you often have to revert to using a scripting language exposed in the app, a DSL, or not infrequently to write a plugin in C++ outside the app entirely. I have seen precious few node and wire tools that actually allow you to express iteration with nodes, or make dynamic function calls (as in recursion). But I'd say a system that doesn't have a way to express those things isn't a programming language, and in particular exposing a different programming language in order to make them expressible doesn't count.

FYI, Luna just closed a round of $2 million financing, so they now can survive for a few more years. I could tell they were running out of money, as they had underestimated how long it was going to take when they started. I agree that exposing Haskell to the users is a huge design flaw that they will eventually have to correct if they want to succeed. Haskell is not beginner friendly. It is highly abstract, and quite weird especially to beginning programmers, which is perhaps half the entire user base.