Well, I’m not sure there was ever a line ;).
I think the “line” is more task-based. Are you “programming” an application that will be used by many people, support the business, and even implement main parts of the business? Or are you “scripting” to automate back-end administrative tasks?
PowerShell’s weaknesses in “programming” tend to come in around its lack of higher-end programmatic structures like classes, inheritance, strict scoping, and that kind of thing. v5 is a huge step in addressing the high end, actually.
Where PowerShell confuses people and blurs lines is that it’s fine if you want to hack out a quick maintenance script with it - or if you want to code up a class-based, heavily modularized, multi-file opus that presents user interfaces and manages an entire business process. It can do both. But it doesn’t directly compile (neither, really, does C#, if you think about it), and it doesn’t offer a lot of high-generation language features. It also - to date - isn’t accompanied by the sophisticated tooling that a developer is usually used to, although that’s starting to change.
If we wanted to make strict definitions, I would say “scripting” is a form of programming; all scripts are programs. Not all programs are scripts. Scripts tend to be procedural, beginning-to-end lines of commands. Literally, a script, like in a movie, that the computer performs. Other forms of programming may result in event-driven user interfaces that don’t run end-to-end. Scripts are common in systems administration because we’re usually using them to automate strict sequences of events. It’s still programming - just with a purpose that might be different from other uses of programming. Other approaches to programming might involve applications, which combine dozens of mini-scripts, along with event-driven triggers, to create interactive interfaces.