take out currently

website/docs/cli/commands/index.mdx

@@ -107,8 +107,7 @@ even when you specify `-chdir=...`:
 ## Shell Tab-completion
 
 If you use either `bash` or `zsh` as your command shell, Terraform can provide
-tab-completion support for all command names and (at this time) _some_ command
+tab-completion support for all command names and some command arguments.
-arguments.
 
 To add the necessary commands to your shell profile, run the following command:
 
@@ -126,9 +125,6 @@ manually in the shell profile, run the following command:
 terraform -uninstall-autocomplete
 ```
 
-Currently not all of Terraform's subcommands have full tab-completion support
-for all arguments. We plan to improve tab-completion coverage over time.
-
 ## Upgrade and Security Bulletin Checks
 
 The Terraform CLI commands interact with the HashiCorp service

website/docs/cli/commands/validate.mdx

@@ -89,7 +89,7 @@ stream. The top-level JSON object will have the following properties:
 
 The nested objects in `diagnostics` have the following properties:
 
-- `severity` (string): A string keyword, currently either `"error"` or
+- `severity` (string): A string keyword, either `"error"` or
   `"warning"`, indicating the diagnostic severity.
 
   The presence of errors causes Terraform to consider a configuration to be

website/docs/cli/import/importability.mdx

@@ -2,21 +2,15 @@
 page_title: 'Import: Resource Importability'
 description: |-
   Each resource in Terraform must implement some basic logic to become
-  importable. As a result, not all Terraform resources are currently importable.
+  importable. As a result, you cannot import all Terraform resources.
 ---
 
 # Resource Importability
 
 Each resource in Terraform must implement some basic logic to become
-importable. As a result, not all Terraform resources are currently importable.
+importable. As a result, you cannot import not all Terraform resources.
-For those resources that support import, they are documented at the bottom of
-each resource documentation page, under the Import heading. If you find a
-resource that you want to import and Terraform reports that it is not
-importable, please report an issue in the relevant provider repository.
 
-Converting a resource to be importable is also relatively simple, so if
+The resources that you can import are documented at the bottom of
-you're interested in contributing that functionality, the Terraform team
+each resource documentation page in the [Terraform Registry](https://registry.terraform.io/). If you have issues importing a resource, report an issue in the relevant provider repository.
-would be grateful.
 
-To make a resource importable, please see
+To make a resource importable, refer to [Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).
-[Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).

website/docs/cli/install/apt.mdx

@@ -69,7 +69,7 @@ To configure your repository:
 
 ## Supported Architectures
 
-The HashiCorp APT server currently has packages only for the `amd64`
+The HashiCorp APT server has packages only for the `amd64`
 architecture, which is also sometimes known as `x86_64`.
 
 There are no official packages available for other architectures, such as
@@ -78,7 +78,7 @@ There are no official packages available for other architectures, such as
 
 ## Supported Debian and Ubuntu Releases
 
-The HashiCorp APT server currently contains release repositories for the
+The HashiCorp APT server contains release repositories for the
 following distribution releases:
 
 * Debian 8 (`jessie`)

website/docs/cli/install/yum.mdx

@@ -58,7 +58,7 @@ yum install terraform
 
 ## Supported Architectures
 
-The HashiCorp Yum/DNF server currently has packages only for the `x86_64`
+The HashiCorp Yum/DNF server has packages only for the `x86_64`
 architecture, which is also sometimes known as `amd64`.
 
 There are no official packages available for other architectures, such as
@@ -67,7 +67,7 @@ There are no official packages available for other architectures, such as
 
 ## Supported Distribution Releases
 
-The HashiCorp Yum server currently contains release repositories for the
+The HashiCorp Yum server contains release repositories for the
 following distribution releases:
 
 * AmazonLinux 2
@@ -95,8 +95,8 @@ more than one version at a time, and `yum install` or `dnf install` will
 default to selecting the latest version.
 
 It's often necessary to match your Terraform version with what a particular
-configuration is currently expecting. You can use the following command to
+configuration is currently expecting. Use the following command to
-see which versions are currently available in the repository index:
+retrieve the available versions in the repository index:
 
 ```bash
 yum --showduplicate list terraform

website/docs/cli/plugins/index.mdx

@@ -12,8 +12,7 @@ of resources. (For more information about providers, see
 [Providers](/language/providers) in the Terraform
 language docs.)
 
--> **Note:** Providers are currently the only plugin type most Terraform users
+-> **Note:** Providers are the only plugin type most Terraform users interact with. Terraform also supports third-party provisioner plugins, but
-will interact with. Terraform also supports third-party provisioner plugins, but
 we discourage their use.
 
 Terraform downloads and/or installs any providers

website/docs/cli/plugins/signing.mdx

@@ -9,7 +9,7 @@ description: >-
 
 # Plugin Signing
 
-~> **Note** Currently only provider plugins fetched from a registry are authenticated.
+~> **Note** Terraform only authenticates provider plugins fetched from a registry.
 
 Terraform providers installed from the Registry are cryptographically signed, and the signature is verified at time of installation. There are three types of provider signatures, each with different trust implications:
 

website/docs/internals/credentials-helpers.mdx

@@ -140,8 +140,8 @@ stream and then exiting with a non-zero status code.
 
 ## Handling Unsupported Credentials Object Properties
 
-Currently Terraform defines only the `token` property within JSON credentials
+Terraform defines only the `token` property within JSON credentials
-objects, but this format might be extended in future.
+objects.
 
 If a credentials helper is asked to store an object that has any properties
 other than `token` and if it is not able to faithfully retain them then it

website/docs/internals/json-format.mdx

@@ -49,7 +49,7 @@ The JSON output format consists of the following objects and sub-objects:
 
 ## State Representation
 
-Because state does not currently have any significant metadata not covered by the common values representation ([described below](#values-representation)), the `<state-representation>` is straightforward:
+Because state does not  have any significant metadata not covered by the common values representation ([described below](#values-representation)), the `<state-representation>` uses the following format:
 
 ```javascript
 {
@@ -612,7 +612,7 @@ A `<change-representation>` describes the change to the indicated object.
 
 ## Checks Representation
 
-~> **Warning:** The JSON representation of "checks" is currently experimental
+~> **Warning:** The JSON representation of "checks" is experimental
 and some details may change in future Terraform versions based on feedback,
 even in minor releases of Terraform CLI.
 
@@ -627,8 +627,7 @@ A `<checks-representation>` describes the current state of a checkable object in
       // "kind" specifies what kind of checkable object this is. Different
       // kinds of object will have different additional properties inside the
       // address object, but all kinds include both "kind" and "to_display".
-      // Currently the two valid kinds are "resource" and "output_value", but
+      // The two valid kinds are "resource" and "output_value".
-      // additional kinds may be added in future Terraform versions.
       "kind": "resource",
 
       // "to_display" contains an opaque string representation of the address

website/docs/internals/login-protocol.mdx

@@ -51,7 +51,7 @@ The properties within the discovery object are as follows:
   specific mechanism by which an OAuth server authenticates the request and
   issues an authorization token.
 
-  Terraform CLI currently only supports a single grant type:
+  Terraform CLI supports a single grant type:
 
   * `authz_code`: [authorization code grant](https://tools.ietf.org/html/rfc6749#section-4.1).
     Both the `authz` and `token` properties are required when `authz_code` is

website/docs/internals/machine-readable-ui.mdx

@@ -136,7 +136,7 @@ At the end of a plan or before an apply, Terraform will emit a `planned_change`
 - `resource`: object describing the address of the resource to be changed; see [resource object](#resource-object) below for details
 - `previous_resource`: object describing the previous address of the resource, if this change includes a configuration-driven move
 - `action`: the action planned to be taken for the resource. Values: `noop`, `create`, `read`, `update`, `replace`, `delete`, `move`.
-- `reason`: an optional reason for the change, currently only used when the action is `replace` or `delete`. Values:
+- `reason`: an optional reason for the change, only used when the action is `replace` or `delete`. Values:
   - `tainted`: resource was marked as tainted
   - `requested`: user requested that the resource be replaced, for example via the `-replace` plan flag
   - `cannot_update`: changes to configuration force the resource to be deleted and created rather than updated

website/docs/internals/module-registry-protocol.mdx

@@ -147,9 +147,7 @@ $ curl 'https://registry.terraform.io/v1/modules/hashicorp/consul/aws/versions'
 The `modules` array in the response always includes the requested module as the
 first element.
 
-Other elements of this list are not currently used. Third-party implementations
+Terraform does not use the other elements of this list. However, third-party implementations should always use a single-element list for forward compatiblity.
-should always use a single-element list for forward compatiblity with possible
-future extensions to the protocol.
 
 Each returned module has an array of available versions, which Terraform
 matches against any version constraints given in configuration.

website/docs/internals/provider-network-mirror-protocol.mdx

@@ -149,9 +149,7 @@ A successful result is a JSON object containing a single property `versions`,
 which must be a JSON object.
 
 Each of the property names of the `versions` object represents an available
-version number. The property values must be objects, but no properties are
+version number. The property values must be objects, but no properties are defined for those objects. We recommend leaving those objects empty.
-currently defined for those objects. We recommend leaving those objects
-empty.
 
 Return `404 Not Found` to signal that the mirror does not have a provider
 with the given address.

website/docs/internals/provider-registry-protocol.mdx

@@ -294,11 +294,11 @@ A successful result is a JSON object with the following properties:
   _required_ for describing an individual provider package so that Terraform
   CLI can avoid downloading a package that will not be compatible with it.
 
-* `os` (required): this must currently echo back the `os` parameter from the
+* `os` (required): this must echo back the `os` parameter from the
-  request. Other possibilities may come in later versions of this protocol.
+  request.
 
-* `arch` (required): this must currently echo back the `arch` parameter from the
+* `arch` (required): this must echo back the `arch` parameter from the
-  request. Other possibilities may come in later versions of this protocol.
+  request. 
 
 * `filename` (required): the filename for this provider's zip archive as
   recorded in the "shasums" document, so that Terraform CLI can determine which

website/docs/language/expressions/type-constraints.mdx

@@ -96,9 +96,8 @@ The three kinds of collection type in the Terraform language are:
   for single line maps. A newline between key/value pairs is sufficient
   in multi-line maps.
 
-  Note: Although colons are valid delimiters between keys and values,
+  -> **Note:** Although colons are valid delimiters between keys and values, `terraform fmt` ignores them. In contrast, `terraform fmt` attempts to vertically align equals signs.
-  `terraform fmt` currently ignores them (whereas `terraform fmt`
+  
-  attempts to vertically align equals signs).
 * `set(...)`: a collection of unique values that do not have any secondary
   identifiers or ordering.
 

website/docs/language/modules/syntax.mdx

@@ -134,8 +134,7 @@ described in more detail in the following pages:
   [the `depends_on` page](/language/meta-arguments/depends_on)
   for details.
 
-In addition to the above, the `lifecycle` argument is not currently used by
+Terraform does not use the `lifecycle` argument.
-Terraform but is reserved for planned future features.
 
 ## Accessing Module Output Values
 

website/docs/language/modules/testing-experiment.mdx

@@ -270,7 +270,7 @@ functionality and so with that in mind there are some specific possibilities
 that we know the current prototype doesn't support well:
 
 * Testing of subsequent updates to an existing deployment of a module.
-  Currently tests written in this way can only exercise the create and destroy
+  Tests written in this way can only exercise the create and destroy
   behaviors.
 
 * Assertions about expected errors. For a module that includes variable

website/docs/language/providers/requirements.mdx

@@ -271,9 +271,8 @@ incompatibilities, and let the root module manage the maximum version.
 
 ## Built-in Providers
 
-While most Terraform providers are distributed separately as plugins, there
+Most Terraform providers are distributed separately as plugins, but there
-is currently one provider that is built in to Terraform itself, which
+is one provider that is built into Terraform itself. This built-in plugin provides the
-provides
 [the `terraform_remote_state` data source](/language/state/remote-state-data).
 
 Because this provider is built in to Terraform, you don't need to declare it

website/docs/language/settings/backends/remote.mdx

@@ -18,7 +18,7 @@ You can also use Terraform Cloud with local operations, in which case only state
 
 ## Command Support
 
-Currently the remote backend supports the following Terraform commands:
+The remote backend supports the following Terraform commands:
 
 - `apply`
 - `console` (supported in Terraform >= v0.11.12)