I'm having myself my share of problems with springs right now. I don't think I can help you, but I'll be waiting for a demo of your spring system.

Gravity shouldn't be too bad , just add the acceleration of gravity to all the particles in your system , find out how much force it causes according to their mass , calculate resultant counter-forces from fixed points and tension in connected objects , sum all the forces on each object , calculate their accelerations and then you can find their new positions. Geez , it's so simple , cmon. (Just kidding)

What are you using the tiny points and lines for? Also , how are you simulating ropes? Are they a collection of connected springs to propagate tension along the points of the rope?

From my experience, handling bodies during collision detection as a set of points and lines is really a pain in the butt.
I'm guessing you're just doing line intersection checks?
If your collision detection handling is static, you'll obviously miss a lot of collisions.
If it's dynamic, you'll probably be able to detect collisions, but how to resolve them is not always obvious, with special cases to consider.
I would recommend you to handle anything you can as polygons.
Try implementing SAT (Separating Axis Theorem), for example.
It would be more simple and efficient for polygonal objects, and if you extend it for dynamic collision detection, (which isn't really that hard), you'll be able to correctly handle separate lines and points as well.

[EDIT]

Consider these cases:

In the top case, the collision would just be missed.
You could pretend that it's the horizontal line that's moving with '-v' towards the vertical and handle the case, but you'd have to detect that.

In the bottom illustration, you see plenty of intersection points but it's not so obvious what to move where.

Well...it'd catch the collision, but nothing would happen...but that's just because I still haven't gotten around to having the point impart force on springs they collide with. Soon as that's handled (which is something I need to do anyway...any two moving objects smacking into each other will behave awkwardly in my system at the moment), it'll work.

Yeah, that'd work just fine. Each point would get properly deflected, and the springs would do the rest.

Yeah! I'd have been mad as hell if that was the problem... But strangely, it didn't seem to make a difference, really...hmm...

Well...that's handy! It seems like I've seen something like that somewhere... It tests (a*d >= b*c) for true or false, and gives the first or second value based on the result, right?

[edit] Actually... I don't think it'd catch that top collision... I should change the checks to make them use relative velocity, rather than absolute velocity. That'd fix it, I think.

You may look at some 2D and 3D engines. Since they deal with most of the stuff the programmers on a.cc deal with, especially with your kind of math and spring collisions, they may be worth a look.

Well, you see, relative velocity is great, but it basically means that you have to treat one object as static, and the other object as moving with the relative velocity.
The problem is that you have to chose which object would be the moving one correctly, or you'll get nonsensical collision information.
As for the first example I gave (with the polygon), sure, your system would handle it, but it would look more ridiculous the more rigid the body is.

[EDIT]

Some more bad cases:
http://img502.imageshack.us/img502/5980/evil2cy7.png
Sure, you could work around it, but it wouldn't be very fast, nor very elegant.
Been there, done that, it's just not worth the burden.

Doing silly redundant tests would solve one problem, but introduce a new one:
In some cases, you'd get conflicting results and you'll have to chose which one to use.
Just look at the picture above and imagine doing the check the other way around like you suggest.
Anyway, I'm getting sort of tired of showing you why your system is flawed.
Have fun killing the FPS of your program while still getting incorrect collision data.

[EDIT]

This is how I see it:
{"name":"evil3ol4.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/d\/0df48a657431dd33797dc8459cd3bbe1.png","w":442,"h":252,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/d\/0df48a657431dd33797dc8459cd3bbe1"}
Two different results...
Perhaps I'm just stupid and I'm misunderstanding your idea?
Could you illustrate?

Time steps have been taken into account.
The picture shows the line in the current frame and the arrow tips show where it's gonna be in the next frame.
Think it's improbable that an object would move that much during one frame?
They do it all the time.
Plus, this problem comes in many variations... The velocity needed to wreck havoc on your program would depend on things like object size and line angle.

P.S.:
Yes, using SAT would be much, much faster, and more reliable.
You don't treat each point or line as a sphere or rectangle or what ever.
Your points ,and lines make polygons so you do polygon vs. polygon tests.
And if you have some lines that stand alone (like rope segments), SAT can handle them just fine the same way it handles polygons.
And it's really not a complicated concept, nor is it complicated to implement.
SAT should be faster than what you're currently doing even in the worst-case scenario, but since objects are more likely not to collide than to collide, a separating axis could very quickly be found and you'd know right away that the objects don't collide.
The idea is basically that if you find an axis, project the objects on it and their projections don't overlap, this axis separates the objects and they can't collide.
There could be infinitely many such axes, but you only need to check a handful:
To be precise, the normal of each side of each polygon is a potential separating axis.
Doing the projection merely requires a dot product, and the overlap test is a small 'if' statement.
In the worst case, you'd have to check every potential axis and if none of them separate the objects, they're colliding, but if the objects don't collide, you quickly find a separating axis and terminate the test.
With your algorithm, you'd have to check every line against every line no matter what.

If you really don't want to treat every object as a whole, I guess you could treat them as sets of line segments and still use SAT, but you'd lose some of its important advantages, plus, you'd have to tweak it a bit and make the collision detection dynamic.
In fact, I had a soft body demo somewhere around where I used thin rectangles instead of line segments to make the soft body, because I was too lazy to code a dynamic SAT.
Rectangles have some area so they're less likely to just pass through each other between frames, so static checks worked fine, but if I had my jelly object to move at high speed, it would pass through other jelly objects. (But not through the map geometry, which is thick.)
I guess it all boils down to this:
If your system works fine for you in normal situations, and you don't need something fool-proof, don't bother... What you're doing should work for small time steps, medium velocities and for bodies that aren't too rigid.
Dynamic SAT would be fool-proof and not TOO hard to implement, plus, if you ever decide to use polygons in another project, you'd have something convenient and efficient ready for use. (It would surely be useful for the conventional types of games that use polygons to represent the world and bounding areas of entities, like a side-scroller...)

Your algorithm is dynamic. But the simple, straight-forward implementation of SAT is not dynamic in the sense that it doesn't take velocities into account, just handles overlaps. Static tests work just fine for polygons at reasonable velocities, they'd work fine for line-vs-polygon, too, but not for line-vs-line cases.
If you use dynamic SAT and treat your objects as a set of segments, you can't use that nice early-out option of finding one separating axis that separates the two objects, but you'd have to treat each segment as an object and check every segment against every other segment, which is kinda what you're doing now... But at least it would be fool-proof. (And probably still somewhat faster.)

[EDIT]

Found that soft body demo.
I'll attach it.
In case you're wondering, it doesn't use any springs at all. I use a more stable technique.

No, it would work perfectly fine...
It's just that when you check a whole object against another whole object, you can find one separating axis and quit checking those objects.
If you divide your objects into parts like line segments and points, you'd have to treat each line segment and point as a separate object, that is, you'd have to find a separating axis between every two segments before you know the objects aren't colliding.
It would be like doing polygon-vs-polygon in the worst-case scenario.

[EDIT]

Maybe you've seen it at the Depot?
I posted it there a while back.
And no, no springs. Just soft stick constraints for surface tension and real pressure calculations for inner pressure. (That is, I use infinitely-stiff "springs", and every time the length of the springs is illegal, I just change the positions of the points to change it back, then work out the velocities from the changes in position. I can make the springs appear "soft" and springy by not putting the points in the correct positions right away, but dragging them a bit in that direction.)

[EDIT 2]

There's no much point discussing SAT... If you want to, read about it a bit, to understand the principle, then decide if you need it or not.

Oh, damn, I forgot...
SAT works only for nice, convex shapes.
And you probably want something that works with any arbitrary shapes.
I'm an idiot.
You can still just do your line\segment tests using dynamic SAT, because it would be fool-proof and somewhat faster.
To be honest, I now realize my points were somewhat moot... If your objects won't be moving too fast and you just want to get things done quick, I guess you better stick to what you have now.