You asked why I'm still a proponent of Stored procs - tell you what...fire up the latest CTP or Beta that you have, and create some linq to sql queries between related master and child tables. Then look at the generated SQL code.Obviously I've done this before. What I (thought I) saw was injection-proof parameterized T-SQL structured for server compilation. Joins were automatic. So can you be more explicit?
If you're determined to use SPs, did you check out the ability to call SPs as a method on the DataContext?
Then you may realize what most Oracle people and a number of SQL Server people are saying - that they'd rather write their own sproc code.That's odd, bearing in mind that you can't use Linq to SQL against Oracle yet ;-) but in any case, this is a non-sequitur. If "something" is wrong with the SQL in the beta, that doesn't lead directly to coding your own SPs. The two aren't mutually exclusive- you can even create SPs right there on the design surface if you must.
"... They ne'er cared for us
yet: suffer us to famish, and their store-houses
crammed with grain; make edicts for usury, to
support usurers; repeal daily any wholesome act
established against the rich, and provide more
piercing statutes daily, to chain up and restrain
the poor. If the wars eat us not up, they will; and
there's all the love they bear us."
-- Shakespeare: Coriolanus, Act 1, scene 1