Apply suggestions from code review

Co-authored-by: Arthur S <36887373+arixmkii@users.noreply.github.com>
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>

Author: 3 people

blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md

@@ -15,7 +15,7 @@ Scala 3.4.0 code can use dependencies compiled with Scala 3.3.x, but not the oth
 
 If you are working on a project that is not meant to be used as an external dependency, feel free to update to Scala 3.4.0, especially if you are starting a new project.
 
-Scala 3.4.0 and 3.3.3 share most of the changes since the 3.3.1 version. The difference is that Scala 3.4.0 adds new features and deprecates legacy mechanisms, while version 3.3.2 is focused solely on bug fixes and usability improvements. What's more, 3.3.2, as a part of the LTS line, maintains not only full binary compatibility but also full source compatibility. **We checked that every single one of over a thousand projects that worked with 3.3.1 still work with 3.3.2.** To achieve this, we had to be extra careful with selecting changes for that release. Thus, not every bug that is fixed in 3.4.0 is also fixed in 3.3.2. Some of the not-ported changes might still land in 3.3.4.
+Scala 3.4.0 and 3.3.3 share most of the changes since the 3.3.1 version. The difference is that Scala 3.4.0 adds new features and deprecates legacy mechanisms, while version 3.3.3 is focused solely on bug fixes and usability improvements. What's more, 3.3.3, as a part of the LTS line, maintains not only full binary compatibility but also full source compatibility. **We checked that every single one of over a thousand projects that worked with 3.3.1 still work with 3.3.3.** To achieve this, we had to be extra careful with selecting changes for that release. Thus, not every bug that is fixed in 3.4.0 is also fixed in 3.3.3. Some of the not-ported changes might still land in 3.3.4.
 
 ## ...wait, what happened to 3.3.2?
 
@@ -108,7 +108,7 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
 - An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code. Originaly it was presented in [SIP-52](https://docs.scala-lang.org/sips/binary-api.html).
 - `-experimental` compiler flags will mark all top-level definitions as `@experimental`. This means that the experimental language features and definitions can be used in the project. Note that this does not change the strong guarantees of the stability of the non-experimental code. The experimental features can only be used in an experimental scope (transitively). In 3.5, we plan to allow using this flag also in the stable releases of the compiler.
 
-### Legacy syntax depreacation
+### Legacy syntax deprecation
 
 Following syntax is now deprecated and will report warnings when used: